First let me say that this issue is with a CentOS server… I use SUSE as my desktop. Plus, my knowledge on routing is extremely limited, I’ve never really had to use it before.
Here’s my issue, I have 2 public IPs assigned from DHCP, but only one of them is usable.
I’m fairly sure that this is a routing issue, or it’s an issue with the DHCP client overwriting the routing table… Or maybe a combination of both?
here’s the out put of ip route list:
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.1
70.75.20.0/22 dev eth2 proto kernel scope link src 70.75.21.249
70.75.24.0/22 dev eth1 proto kernel scope link src 70.75.27.189
169.254.0.0/16 dev br0 scope link
default via 70.75.20.1 dev eth2
As most people will probably guess, eth2 is the only one that’s working. I’ve punched a hole in my firewall to allow pinging of those 2 IPs, but only 70.75.21.249 responds.
Thanks in advance for the help!!
Where are you pinging from? The way you have it set up, if you are pinging from
70.75.20.0/22 the answer will be from 70.75.21.249, and if you are pinging from 70.75.24.0/22 the answer will be from 70.75.27.189. From other addresses, ignoring localhost and the 169.254.0.0/16 addresses, the answer will be from 70.75.27.189 routed through 70.75.20.1. That’s what your rules specify.
I have no idea what these rules specify, they’re what’s being set by CentOS and the DHCP client as I have already said.
I’m using a remote ping service… and if I try to host a website at the 70.75.27.189 IP, no one outside of my LAN can access it.
The problem is you specified the default route to be through eth2, which means that any answer will come from 70.75.21.249, which is not what the sender is expecting, so reply packets get dropped. In other words, packets can reach your server at 70.75.27.189, but your server doesn’t know how to route the replies back correctly. Routing needs to be correct at all points along the path. Just because the packets can be correctly routed inwards doesn’t mean the outward routing will be correct.
You’re going to have to use some advanced routing magic like the methods described here to ensure that the reply packets go out via the right interface:
10.4. Multiple Connections to the Internet
Are you sure you need this sort of hassle? Can you not bind all your externally visible services to the default interface?
A slight error and clarification:
70.75.21.249, which is not what the sender is expecting
What happens is that the packet will have a source of 70.75.27.189, but it will go out the 70.75.21.249 interface due to your default route. This is not acceptable to the next hop so the packet gets dropped.
The maxim is: routing is stateless. There isn’t any information attached to a packet that says, hey, this came in from interface A, make sure that any reply packets go back out the same interface A. The metaphor of a connection as being like a pipe between two hosts breaks down at the packet level when routing is considered. You only have the pipe when the routing is correct at all points in the path.
I seem to have gotten half of it working… my internet connection seems unstable though, most pages usually load in under a second, now they take at least 5 seconds to load, and some don’t even load.
Hmm, maybe it is too much trouble, oh well, it was worth a shot… thanks for your help too, it got me pointed in the right direction, I forgot to mention I use shorewall as a front end to iptables.
Anyways, thanks again!lol!