19

one of my servers (Debian 5.0.6) has two public ip-address on the same interface. This used to work well for months but suddenly it is using "the wrong" ip addresses for outgoing connections. This is a problem because the reverse lookup will not match and emails therefore get spam points.

eth0      Link encap:Ethernet  Hardware Adresse 00:1b:21:14:8e:9c  
          inet Adresse:81.169.180.51  Bcast:81.169.180.51  Maske:255.255.255.255
          inet6-Adresse: fe80::21b:21ff:fe14:8e9c/64 Gültigkeitsbereich:Verbindung

eth0:0    Link encap:Ethernet  Hardware Adresse 00:1b:21:14:8e:9c  
          inet Adresse:85.214.157.120  Bcast:85.214.157.120  Maske:255.255.255.255


Kernel-IP-Routentabelle
Destination     Router          Genmask         Flags Metric Ref    Use Iface
81.169.180.1    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
0.0.0.0         81.169.180.1    0.0.0.0         UG    0      0        0 eth0

Currently it is using 85.214.157.120 for outbound connections. How do I get it to use 81.169.180.51?

Edit: The netmask of 255.255.255.255 is consistent with both documentation and DHCP response of the hosting company. Calling /etc/init.d/networking restart multiple times will eventually end up with the correct ip-address for outbount connections. But that is obviously not a stable solution. /Edit

Edit 2: To make sure that the host route is not related to my issue, I setup a local test network:

eth0      inet Adresse:192.168.0.2  Bcast:192.168.0.255  Maske:255.255.255.0
eth0:0    inet Adresse:192.168.0.3  Bcast:192.168.0.255  Maske:255.255.255.0

192.168.0.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0        192.168.0.1     0.0.0.0         UG    0      0        0 eth0

If anyone has an idea how to make sure that source ip-address 192.168.0.2 is used on outbound tcp connections, I'd be thankful. /Edit 2

Hendrik Brummermann
  • 336
  • 2
  • 4
  • 11

6 Answers6

27

Update default:

ip route change default via 81.169.180.1 src 81.169.180.51

Check configuration:

ip route list
Koen.
  • 826
  • 9
  • 10
bindbn
  • 5,153
  • 2
  • 26
  • 23
3

The answer by bindbn is good, but I found some complications.

1) You should check "ip route list" as bindbn says. Some other rule in the list may take precedence over the default route. You might need to delete that rule, or create a slightly different rule.

2) All changes done via the ip command only work until next reboot. This answer Permanently adding source policy routing rules explains how to make it persistent.

In summary, you can add the ip route command you need to run as an "up" or "post-up" line to /etc/network/interfaces. You could add a corresponding "down" line to remove the route.

Community
  • 1
AdamS
  • 131
  • 2
1

Out of curiosity, why do your IP addresses have a netmask of 255.255.255.255 ? That's really not feasible, since it would mean the whole address is the network. No room for hosts. The fact that your broadcast address is the same as your host IP is also worrying, but likely due to the netmask issue. It rather looks like your netmask should be 255.255.255.0.

Was this done to give you two hosts on the same subnet? It might be preferable to simply make a change so that each interface is on a different subnet. 255.255.255.128 would put eth0 and your gateway (of 81.169.180.1) on the same subnet, with eth0:0 on a separate subnet. However, that would mean that eth0 could only communicate with 81.169.180.1-81.169.180.127. And eth0:0 going from 129-254. But that being said, I can't really see why your current setup works at all.

Now, will this cause the issues you're seeing above? I can't see a direct link, but it's possible.
It's certainly something I'd tweak. If that doesn't help, maybe you can explain why you have things setup this way.

Edit: Was this working fine on this host, or was it a different machine/OS? Any idea what might have changed? The reason I ask is because Linux really doesn't like to have two interfaces on the same subnet. It's driven me mad trying to get this working on my own network. It sounds quite possible that you got this working on the right IP, up until you rebooted/restarted network services. Then it came up using the wrong interface. Reference: http://anders.com/cms/258

You could also try ifdown on eth0:0, then adding the route, then ifuping it back. That might guarantee the correct IP gets used.

Manually adding the dev eth0 might help, but it appears as though the route was done properly.

Further Edit: You might try using the newest IP management tools in Debian, iproute 2. (Secondary link) It looks like something along the lines of
Bringin up the interface: ip link set eth0 up

ip addr add 192.168.0.2/24 dev ethe0
ip addr add 192.168.0.3/24 dev eth0

Then setting up the routing table with
ip route add 10.0.0.0/16 via 192.168.0.2


--Christopher Karel

Christopher Karel
  • 6,442
  • 1
  • 26
  • 34
  • A netmask of 255.255.255.255 is consistent with both the documentation of the hosting company and the DHCP response. According to Google it is normal to have 255.255.255.255 on point to point networks. As far as I can tell, it would be rather stupid of the hosting company to use a none point to point network given the security risk of having untrusted hosts in the same layer 2 broadcast domain. – Hendrik Brummermann Sep 18 '10 at 22:21
  • Like Wolfgangsz was saying above, a /32 is not a standard for a point to point link. I know a /31 can be done, but obviously kills off the broadcast and network identifiers. The 'host route' you saw mentioned refers to it's use in routing tables. eg: It's a route to a specific host, not to a network. Hence its occurrence in the RFC you linked on OSPF, a routing protocol. That being said, if you're sure your ISP instructs you to do that with your OS, then you might as well keep it up. – Christopher Karel Sep 19 '10 at 04:11
  • OK, a few edits made, that might help your original issue. – Christopher Karel Sep 19 '10 at 05:06
1

Try changing 

 allow-hotplug eth0

to

 auto eth0

That should force your physical interface to come up first. You may or may not need to change the allow-hotplug entry for eth0:0 as well.

Bill B
  • 591
  • 2
  • 4
0

10 years has passed, iproute2 is happened, however the related answer
https://unix.stackexchange.com/a/611945/214557

Alex
  • 262
  • 3
  • 6
-1

Your current setup shouldn't actually work at all. Since the netmask for both interfaces is 255.255.255.255, there is no room for a gateway. However, in order to deliver any meaningful traffic, your server needs a gateway. The ISP providing the two public IP addresses should also provide you with netmask and gateway settings for both IP addresses.

Example (this is my private server and the IP addresses are real):

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
217.10.144.208  0.0.0.0         255.255.255.248 U     0      0        0 eth0
0.0.0.0         217.10.144.209  0.0.0.0         UG    0      0        0 eth0

The server itself is on 217.10.144.210, which lies in the same subnet as the gateway (has to, otherwise no traffic can be routed). Presumably the ISP is providing the same subnet for some other customers, too.

If you are on that server and you do a ping to your gateway, you should receive a "no route to host" message.

Talk to the ISP and get the correct settings, then update your interface configuration, restart networking and check it out again.

wolfgangsz
  • 8,767
  • 3
  • 29
  • 34
  • 2
    A netmask of 255.255.255.255 is consistent with both the documentation of the hosting company and the DHCP response. According to Google it is normal to have 255.255.255.255 on point to point networks. As far as I can tell, it would be rather stupid of the hosting company to use a none point to point network given the security risk of having untrusted hosts in the same layer 2 broadcast domain. – Hendrik Brummermann Sep 18 '10 at 22:20
  • If you have a point-to-point network, then your netmask would be 255.255.255.252. This would allow for the two hosts that make up the two end-points, a network address and a broadcast address. This is the normal scenario for those kind of connections. In your case the other host would then be your gateway to the rest of the world. I don't really care what you dig out on google, but this is how TCP/IP networking works. And quite clearly it's not working for you. I leave the conclusions to you. – wolfgangsz Sep 18 '10 at 23:09
  • Thank you, but this part is working perfectly fine for me. By the way it is called a "host route" in the official Internet standard: http://www.rfc-editor.org/rfc/rfc2328.txt – Hendrik Brummermann Sep 19 '10 at 00:12
  • My problem is reproducible on a local network, too: ifconfig eth0 192.168.0.2 mask 255.255.255.0 / ifconfig eth0:1 192.168.0.3 mask 255.255.255.0 / route add default gw 192.168.0.1 – Hendrik Brummermann Sep 19 '10 at 00:27