Newsroom Update

Beginning in May, a special Today at Apple series titled “Made for Business” will offer small business owners and entrepreneurs free opportunities to learn how Apple products and services can support their growth and success. Learn more >

Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

User profile for user: spell
spell Author
User level: Level 1
0 points

How do you route across a Snow Leopard server?

Hi, Can anyone help me with a routing problem?

I think it's a routing problem…

I'm replacing a Linux server with a Snow Leopard 10.6.2 server. The Linux server is a one-machine firewall/router/nat/vpn/dhcp/ftp/web/mail/file-server. All traffic between the internet and internal LAN pass through it.

My goal is to migrate all Linux services to the SLS and kill power on the Linux box. That process has hit a bump with routing through the SLS.

Internet clients connect to the SLS VPN and can access all IP addresses/services on the internal, 192.168 network -- except the SLS internal 192.168 IP address. When I configure internal clients and servers to use the SLS 192.168 IP as their default gateway, they cannot see (ping or otherwise) the internet facing IP address on the SLS. They can access the internet through that interface, though.

The firewall on the SLS accepts any packet on the 192 network and limits internet traffic to only hosted services (pretty much the default firewall configuration). The NAT service is configured for IP forwarding and NAT.

Is other configuration need so that the SLS routes packets from one of its interfaces to the other?

Mac OS X (10.6.2)

Posted on Feb 25, 2010 3:04 PM

Reply
13 replies
User profile for user: shivets
shivets
User level: Level 1
0 points

Mar 9, 2010 12:54 PM in response to spell

Hello Spell,

I've the exact same issue. I'm currently not running a VPN, but I've set up a LAN that accesses the outside internet through SLS using NAT service plus IP forwarding. I also cannot ping from the internal clients to the internet facing IP. This is a big problem for me, as I am trying to use the SLS server as an Xgrid Controller.

The interesting thing is that doing a traceroute on a packet destined for the internet facing IP doesn't even make it to the default gateway/routing IP. I've been looking at the host tables for a while now, but haven't seen anything wrong.

It also appears to me like a interface routing problem.

Come across any leads?
Reply
User profile for user: spell
spell Author
User level: Level 1
0 points

Mar 9, 2010 7:47 PM in response to shivets

The short answer to your question is: no real progress yet.

I don't believe that the firewall is an issue. I experience the same problem with the firewall disabled and to double check, there are no log entries to indicate that packets traversing the server are dropped.

The Linux machine I want to replace "just works". The routing table has 4 trivial entries -- 3 associate network IP/netmask with interfaces and a default route. The SLS has dozens. Many match arp cache entries, but others don't make sense to me: why are there entries for the SLS-local IPs to 127.0.0.1? or the entries with link#n and use counts of zero? Are these the problem?

Anyway, I'm desperate for a suggestion for something to try/look at...

Good luck.
Reply
User profile for user: JeroenHolland
JeroenHolland
User level: Level 1
20 points

Mar 9, 2010 10:27 PM in response to spell

I had the same problem.
(Clients connected using VPN could only ping local services, but not public internet servers. In my case, the clients weren't accepting the local DNS either.)

I fixed this for myself by using the same subnet/NAT IP range for the VPN connection as the IP range the server is in..

I have no explanation why that fixed it for me though.
Reply
User profile for user: shivets
shivets
User level: Level 1
0 points

Mar 10, 2010 10:34 AM in response to spell

I've got those (link#n, localhost to localhost, zero use counts) in my host tables as well. Research and trial/error in changing the local and interface entries hasn't provided me a solution yet.

I also don't think it's the firewall.

The traceroute and ping behavior of the internet facing IP has me wondering if I've got a routing loop somewhere, since the packets don't seem to bounce off of the LAN facing router/gateway IP address. I'm expecting the LAN facing IP to receive the ping from the client then route it to the destination internet facing IP, so the missing LAN facing IP in traceroute and the "request timeout for icmp_seq" I get with ping are curious. Might this be characteristic of packets continuously getting routed back and forth between the two interfaces? Do you have the same symptoms?

In any case, that's my current angle of attack.
Reply
User profile for user: spell
spell Author
User level: Level 1
0 points

Mar 10, 2010 6:43 PM in response to shivets

I've been looking for a way to trace a packet as it moves through the server. tcpdump is of some use -- confirming that a packet crosses an interface. I've used it to prove that my pings are reaching the server. I'm looking for a way to see what the routing/firewall/nat code are doing with it once it's there. dtrace may be helpful, I'll look into that.

Any other thoughts on methods to confirm how far a packet makes it through the system and/or where it is dropped? (other than the firewall log)
Reply
User profile for user: Eric McMurry
Eric McMurry
User level: Level 1
39 points

Mar 11, 2010 2:29 PM in response to spell

does turning off scoped routing make this work for you?

sudo sysctl -w net.inet.ip.scopedroute=0

If you try this, your routing may entirely break at some indeterminate period a few minutes later. You can put it back with:

sudo sysctl -w net.inet.ip.scopedroute=1

This sounds like a problem I have where the packets get to the server, but the responses are sent out the wrong interface.
Reply
User profile for user: Eric McMurry
Eric McMurry
User level: Level 1
39 points

Mar 12, 2010 5:28 PM in response to spell

I saw it here:

http://discussions.apple.com/thread.jspa?messageID=10358887&#10358887

I've had this problem ever since upgrading to Snow Leopard server and have seen several discussions that looked like the same problem.

I also was able to see the packets going the wrong directions using tcpdump/wireshark. There is a cloned route on my system that does this (use netstat -rna, the 'a' will show cloned routes). The route was for a specific interface. Deleting it just resulted in it being recreated when traffic was received along that path again.

Unfortunately, for me at least, turning off scoped routing only works temporarily. I've had a bug report in for this for a while and it was being looked at at some point. I'm hoping a fix shows up with 10.6.3 or that someone with more clever or time than me comes up with a better work around.
Reply

How do you route across a Snow Leopard server?

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.
Learn more Sign up