Routing Problem

[Matt Wynne]

Hi – apologies for this rather longwinded question but I’ve melted my head trying to do this!!!

I have an unusual routing problem I could do with some help on. We’ve got an Xserve that has an internal IP address of 192.168.1.10/24 on en0 using 192.168.1.249 as it’s router, with the router’s NAT table on a one-one from 1 of 5 external IP addresses (I’m going to call this Connection1 for ease of speech!). Fine, it works a treat.

We also want to provide a secondary way into that server via another broadband connection (different external IP addresses) into en1. I currently have en1 set up as 10.1.0.2/24 using a second router set up as 10.1.0.1. These 2 devices are discretely connected via CAT5.( This is Connection2.)

This is where my problem lies. As long as en0 remains the primary interface, any connection I try to make from the outside world via Connection2, simply times out. Using tcpdump on the connecting machine shows that the responses are coming back from Connection1 not Connection2, so no wonder.

But this is where I’m confused. I thought that an originating packet from 10.1.0.1 (incoming via the external IP address) would be sent back to it? I didn’t expect it to just send it back out via the default gateway? How can I get the Xserve to send packets back via the interface they came from and not anywhere it likes? I’ve tried using route to manually add in entry into the routing table but it won’t take it as one for 10.1.0/24 already exists!!

NAT is not on and the Firewall isn’t a factor either (it does it whether the Firewall is on or not)

Anybody still reading this, you have my deepest gratitude and you’ll get my eternal love (easy tiger!) if you can solve my puzzle.

Cheers

[Anonymous]

I think we had a similar problem…
We solved ours by adding a static route to the Server’s routing table.

Our issue was internal network on one server ethernet port en0 and the internet on a second ethernet port en1. The internal clients could either find either the internet or the internal network’s other subnets but never both. What the clients found was determined by which eithernet port was 1st in the System Preferences>Network>Network port configurations pane (which apparently is the default route used by the server for unknown packets).

I followed the advice in the following Apple discussion to tell the server the static route to our internal network and put the internet ethernet port as the 1st in the System Preferences>Netowork>Network port configurations pane. This way the server knew which way to send the local traffic and everything else went to the internet by default.

http://discussions.apple.com/thread.jspa?threadID=130149&tstart=0

[Matt Wynne]

Thanks for the info but I’ve tried that already – route -n add 10.1.0.1/24 10.1.0.1 results in it reporting that this route already exists. And it does, because I have en1 set to 10.1.0.3, it’s dynamically set the routing table accordingly – and only unknown packets should be going to the the default gateway (192.168.1.249).

And that’s the point, these shouldn’t be unknown packets. If they come from a device in the 10.1.0.1/24 range then by all the IP rules I can find, they should go back to the device that sent them as long as that device has a valid entry in the arp table.

[Matt Wynne]

Having played around a bit with the routing table and using tcpdump to monitor the incoming connections, it seems that the packets that are being passed from the router retain their original IP address/port number. I was under the impression that a NAT router made the packets appear to come from it self, not from the original source. I’ve tried this on 2 different routers and also using the DMZ method and plain old port forwarding, see the following:

Making an ssh connection from a remote ip address (195.172.14.194) to the external ip address of number 2 router (217.36.219.96) with ssh port forwarded to our xserve (10.1.0.3) results in output:

14:34:10.983759 IP 195.172.14.194.50765 > 10.1.0.3.ssh: S 1964128251:1964128251(0) win 65535

See the source? 195.172.14.194!! Not 10.1.0.1. It’s no wonder the route isn’t working because 10.1.0.1 doesn’t appear anywhere. To just to prove the point I added 195.172.14.194 as a static route and it went straight in.

Can someone tell me if I’ve gone completely mad but I thought the whole point of NAT is that it breaks the end-to-end nature of IP addressing? And if so why don’t 2 very popular routers (ZyXel and Draytek) both not work this way.

In the mean time I’m going to have a long bath and read the RFC on NAT!

[Matt Wynne]

Thanks Joel! 🙁

That’s the conclusion I’d come to after getting back to work today after the holidays. Do you/anyone else know of specific hardware devices that would do this? It would save us a lot of searching.

Cheers

[Author]

Posts