VPN and subnet weirdness

Question

Level 1

0 points

VPN and subnet weirdness

When connecting via VPN to my private lan from the internet, the subnet mask is always set to 255.0.0.0, even if the network routing definition says 255.255.255.0, consequently no machines on the lan can be reached.

I have SLS set up as follows:
router and dhcp server on 10.0.1.1
mac mini with dns and vpn server on 10.0.1.2
private lan with address range 10.0.1.100-120
vpn with range 10.0.1.150-175

everywhere subnet mask is 255.255.255.0

if i try to connect from outside, I can do so fine, but the only machine I can see is 10.0.1.2.
if I switch subnet mask to 255.0.0.0 (on dhcp server and network routing definitions) then everything works fine.

Does anyone know what is going on here?

Thanks
Chris

MacMini Server, Mac OS X (10.6.2)

Posted on Jun 7, 2010 3:28 PM

Reply

Answer 1

Jun 8, 2010 12:11 AM in response to zCRP

I've seen intermittent routing/netmask problems with VPN in various versions of OS X before.

This looks like it has to do with the server using the whole 10.0.0.0/8 network netmask.

10.6.3 or upcoming 10.6.4 might solve it.

Network routing definitions only tell the VPN client what network(s) are on the VPN server side but could also mean trouble if the network you connect from is within that range. But you seem to have problems with the opposite.

Are you running a firewall in the VPN server? Ipforwarding is on (in NAT config)?

Also I would probably run the DHCP in the server if the router (AirPort basestation?) doesn't send out search domain info. It might not be possible to turn off DHCP in an AirPort basestation depending on configuration.

Reply

Answer 2

zCRP Author

Level 1

0 points

Jun 8, 2010 1:52 AM in response to Leif Carlsson

I am running dhcp on my router (zyxel usg 100), while the mac mini, which runs the vpn server, does not run firewall not nat.

this same setup used to work until a few days ago, but I have since changed internet provider. I have checked that also before the provider switch, vpn connections would get a 255.0.0.0 net mask, but everything worked fine. with the new provider it does not anymore. Could this be due to the fact that the new provider uses addresses in the 10.x range internally? my lan uses 10.0.1.x and while tracerouting around I found that my provider has a few servers at addresses like 10.0.21.x, 10.251.x.x etc

one more piece of information: upon establishing vpn connection, if I run ifconfig on the server I get
ppp0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
inet 10.0.1.2 --> 10.0.1.151 netmask 0xffffff00

while on the client I get
ppp0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
inet 10.0.1.151 --> 10.0.1.2 netmask 0xff000000

so there's definitely a netmask mismatch

Reply

Answer 3

Jun 8, 2010 2:38 AM in response to zCRP

That's the same thing I have observed with VPN netmasks.

If the ISP use any private IP subnets or not "along the way" shouldn't matter as log as the firewall get a public IP on the WAN port.

I actually tried just now connecting a 10.5.8 L2TP server which run on a 10.0.30.0/24 network, behind a WatchGuard firewall, from my 10.6.3 client and got the exact same errouneous(?) netmask for ppp0.

But it still works accessing machines on that subnet.

It could be a problem if I connect from a network witin the 10.0.0.0/8 range.
I think my 3G modem connects through a 10-network but it still works running VPN to the same site.

You could try just enabling ipforwarding (turn routing on) in the NAT config on the server.

This will also enable access trough the VPN server to Internet if you enable/configure your default route through VPN.

Reply

Answer 4

Jun 8, 2010 7:55 AM in response to zCRP

I would like to confirm this is an issue with 10.6.3 as well.

We use the 172.16.0.0/16 subnet for internal servers and we discovered that anything that wasn't on the VPN subnet wasn't visible. This is because OS X sets the netmask to 255.255.0.0 for the 172.16 network - a /16, when in fact it is a /12.

This has the effect of making any packets destined for 172.17.0.0 and up stay on the local network.

The only two solutions appear to be to either send all traffic over the VPN, which is non-optimal, or to set a route in the /etc/ppp/ip-up file, which is better but not easy to implement with non-technical users, which is the camp most of our Mac users fall into.

It would be really cool if Apple could finally fix VPN, which has been broken in some way since 10.6 came out.

Reply