Server IPv6 address & DA for adding extra IPv6 addresses changes the Server IPv6 addr

J

jvdwilk

Verified User
Joined
Aug 2, 2006
Messages
38
Server IPv6 address & DA for adding extra IPv6 addresses changes the Server IPv6 addr

Server IPv6 address & DA for adding extra IPv6 addresses changes the Server IPv6 address

What I have done:
I have set up a new Centos 6.5 server with both an IPv4 and IPv6 server IP address.
I would want / expect the server to use these addresses when making remote connections for all kinds of services.
I have permitted these server IPv4 and IPv6 addresses in remote nameservers for zone transfers and notification.
I have set up remote firewalls to allow certain connections from these server IPs. All was working fine.

IPv6 is working properly.
In my /etc/sysconfig/network-scripts/ifcfg-eth0 file there is one IPv4 and one IPv6 address for the server.
I would expect these to be my 'server IPs'.

After adding IPv4 addresses in DA for assigning to certain users, there were still no issues.
After adding IPv6 addresses in DA for assigning to users, I noticed the first problems:
The last added IPv6 address started acting as the 'server default' IPv6 address. It started showing up in Firewall logs, DNS logs, mail logs and such. The server had started using this last added IPv6 address as it's default IPv6 address.
After a reboot, it was no longer the last added, but it changed to the highest numbered IPv6 address which was being used as the server default IPv6 address.

Checking the server interface gives a good bit if information, although I am not 'expert' enough to fully understand the implications of all this:

Code: 
[root@seti ~]# ifconfig
eth0      Link encap:Ethernet  HWaddr 52:54:00:2F:5C:16
          inet addr:149.210.159.111  Bcast:149.210.159.255  Mask:255.255.255.0
          inet6 addr: 2a01:7c8:aab4:5e0::fefe/128 Scope:Global
          inet6 addr: 2a01:7c8:aab4:5e0::bebe/128 Scope:Global
          inet6 addr: 2a01:7c8:aab4:5e0::ae06/128 Scope:Global
          inet6 addr: 2a01:7c8:aab4:5e0::ae07/128 Scope:Global
          inet6 addr: fe80::5054:ff:fe2f:5c16/64 Scope:Link
          inet6 addr: 2a01:7c8:aab4:5e0::ae08/128 Scope:Global
          inet6 addr: 2a01:7c8:aab4:5e0::ae09/128 Scope:Global
          inet6 addr: 2a01:7c8:aab4:5e0::ae0a/128 Scope:Global
          inet6 addr: 2a01:7c8:aab4:5e0::ae0b/128 Scope:Global
          inet6 addr: 2a01:7c8:aab4:5e0::9f6f/48 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:898 errors:0 dropped:0 overruns:0 frame:0
          TX packets:903 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:181359 (177.1 KiB)  TX bytes:96715 (94.4 KiB)

eth0:0    Link encap:Ethernet  HWaddr 52:54:00:2F:5C:16
          inet addr:149.210.174.6  Bcast:149.210.174.6  Mask:255.255.255.255
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

eth0:1    Link encap:Ethernet  HWaddr 52:54:00:2F:5C:16
          inet addr:149.210.174.7  Bcast:149.210.174.7  Mask:255.255.255.255
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

eth0:2    Link encap:Ethernet  HWaddr 52:54:00:2F:5C:16
          inet addr:149.210.174.8  Bcast:149.210.174.8  Mask:255.255.255.255
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

eth0:3    Link encap:Ethernet  HWaddr 52:54:00:2F:5C:16
          inet addr:149.210.174.9  Bcast:149.210.174.9  Mask:255.255.255.255
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

eth0:4    Link encap:Ethernet  HWaddr 52:54:00:2F:5C:16
          inet addr:149.210.174.10  Bcast:149.210.174.10  Mask:255.255.255.255
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

eth0:5    Link encap:Ethernet  HWaddr 52:54:00:2F:5C:16
          inet addr:149.210.174.11  Bcast:149.210.174.11  Mask:255.255.255.255
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:246 errors:0 dropped:0 overruns:0 frame:0
          TX packets:246 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:21936 (21.4 KiB)  TX bytes:21936 (21.4 KiB)

[root@seti ~]#


Maybe my ideas are way off or too simple, but I would expect that every IPv6 address I add, would also be added to its own virtual interface (eth0:x) just as how it is being done for an IPv4 address I add through DA, not..? Would that not already solve this issue?
Or are there other / better ways to get rid of this 'odd' behaviour?

I'd love to hear others input?
 
Actually email is the least of all problems related to this.
Exim has a fool-proof solution for setting the sending IP addresses:

insert the following in the exim.conf file, and you're set (change the IPs to your servers IPs):
#COMMENT#61:
remote_smtp:
driver = smtp
interface = <; 149.210.159.111 ; 2a01:7c8:aab4:5e0::9f6f

The real problems come with IPv6 being preferred over IPv4 by most systems - if available -, and that I could have a different IP address every other odd day when I need to add a new IPv6 address to my configuration.
My server is being expected to connect from a predefined IP(v6) address to other servers for sharing information. And this address is changing too many times. It's not 'just' DNS, it is also automated backups, MySQL sessions, and recently even a software license which failed because of the changing IP addresses the connections where coming from.

Since the IPv6 addresses are being inserted through DA I would think DA is responsible for fixing this.
That however would be too obvious if it was that simple. Could anyone explain to me where these IPv6 addresses are being set from, and if there would be a good work around for resolving this if it is not a responsibility of DA?
Where _should_ the IPv6 address have gone to prevent this kind of behavior?
Did I mis-configure something in my IPv6 settings?
I am currently doubting everything I know about IPv6 (which is less then I would have liked..!) and I would really like to know if this is something silly I would have to fix myself, or if this is something complex that I could expect to be fixed in some future DA update?
 
Arieh, thank you very much for that link. Indeed it explains the situation exactly, and I think the offered solution will work.
Probably I will have to add all my IPv6 addresses now two times, both in DA and in my network configuration, and I hope that will not give a conflict.
I'll be doing some testing on this tomorrow or later this week, and then report back here what I find.

Thanks again!
 
jvdwilk said:
and I hope that will not give a conflict.
Click to expand...
DirectAdmin will likely throw an error, showing that the IP# is already added, when the script is run to add IP#s through DirectAdmin. But that's okay; it won't affect anything.

Jeff
 
Well, as I said before, I would do some testing and then report back what I found.

Here is what I found:

The technique works, you can deprecate your IPv6 addresses and if you deprecate all but your server ip, then you have the situation where only your server IPv6 address will be used for connecting to remote servers. So far so good...

The current implementation I found sucks...
I am adding to my /etc/rc.local file a statement for every IPv6 address I have, and need to add every new IPv6 address I add through DA there also, in addition to running the command manually (replace the IPv6 address with your own):
Code: 
ip addr change 2a01:7c8:aab4:5e0::ae06 dev eth0 preferred_lft 0

The only alternative (not really) I see would be to hack into the /usr/local/directadmin/scripts/addip file and edit line 14 to
Code: 
/sbin/ip -6 addr change ${1}${MASK} dev $ETH_DEV preferred_lft 0

And then add your server IPv6 address to the /etc/rc.local file with a preferred_lft 1 behind it.

The obvious problem with this is that if DA updates the addip file, your changes will be lost.

I think this is where DA would have to change something, either allow addip to be overruled in some custom folder (this might already be the case?)
or - preferable - create a hook so that we can run an external script on invoking the addip script ( /usr/local/directadmin/scripts/custom/ipv6_create_post.sh comes to my mind... )
in which we can run one of the above commands...
 
You must log in or register to reply here.
Back
Top