Recently, I’ve been having some trouble getting my VPN connections to work the way I wanted them to on my Mac OS X Tiger machine. In most situations, when you connect to a virtual private network, it’s only logical you become a full member of that network, with access to all of its resources. In real life, this is not always the case, since, for example, allowing a user to use the network’s gateway causes unnessecary strain on the internet connection, but worse: it allows the user access to any resources the gateway has access to. While this might not always be desirable, our universe has actually disallowed it, thus leaving us no choice but to block it in the firewall.
Windows users have a tick box “use default gateway on remote network” for this purpose. The VPN tunnel will then only be used for traffic to that subnet, not for all outgoing traffic. Us Mac users are not so fortunate, since such a feature does not exist in the internet-connect utility. However it is possible. It simply requires some knowledge of the point-to-point daemon (pppd).
This is how it works:
Before setting up a VPN tunnel, ppp first checks /etc/ppp/peers/ for a file matching the connection name, in my case “IA-VPN”. If it exists, its contents are read before ppp goes on to the next file: /etc/ppp/ip-up, which is executed directly after the tunnel is set-up. Before I give you a short howto on turning this into your advantage, let’s see exactly where it goes wrong by looking at a dump created by the command “route monitor”:
got message of size 124 on Thu Jan 12 16:13:13 2006 RTM_DELETE: Delete Route: len 124, pid: 522, seq 1, errno 0, flags:<GATEWAY,HOST,DONE,WASCLONED> locks: inits: sockaddrs: <DST,GATEWAY> eendhoven.ewi.utwente.nl 192.168.0.1 got message of size 140 on Thu Jan 12 16:13:13 2006 RTM_ADD: Add Route: len 140, pid: 522, seq 1, errno 0, flags:<UP,GATEWAY,HOST,DONE,STATIC> locks: inits: sockaddrs: <DST,GATEWAY,NETMASK> eendhoven.ewi.utwente.nl 192.168.0.1 broadcasthost got message of size 112 on Thu Jan 12 16:13:13 2006 RTM_IFINFO: iface status change: len 112, if# 7, flags:<PTP,MULTICAST> got message of size 112 on Thu Jan 12 16:13:13 2006 RTM_IFINFO: iface status change: len 112, if# 7, flags:<PTP,RUNNING,MULTICAST> got message of size 112 on Thu Jan 12 16:13:13 2006 RTM_IFINFO: iface status change: len 112, if# 7, flags:<PTP,RUNNING,MULTICAST> got message of size 80 on Thu Jan 12 16:13:18 2006 RTM_NEWADDR: address being added to iface: len 80, metric 0, flags: sockaddrs: <NETMASK,IFP,IFA,BRD> 255.0.0.0 ppp0 10.10.3.5 10.10.3.1 got message of size 124 on Thu Jan 12 16:13:33 2006 RTM_ADD: Add Route: len 124, pid: 0, seq 0, errno 0, flags:<UP,HOST> locks: inits: sockaddrs: <DST,GATEWAY> 10.10.3.1 10.10.3.5 got message of size 144 on Thu Jan 12 16:13:33 2006 RTM_ADD: Add Route: len 144, pid: 522, seq 1, errno 0, flags:<UP,DONE,STATIC> locks: inits: sockaddrs: <DST,GATEWAY,NETMASK> 10.0.0.0 ppp0 255.0.0.0 got message of size 112 on Thu Jan 12 16:13:33 2006 RTM_IFINFO: iface status change: len 112, if# 7, flags:<UP,PTP,RUNNING,MULTICAST> got message of size 128 on Thu Jan 12 16:13:33 2006 RTM_DELETE: Delete Route: len 128, pid: 44, seq 22, errno 0, flags:<GATEWAY,DONE,STATIC,PRCLONING> locks: inits: sockaddrs: <DST,GATEWAY,NETMASK> default 192.168.0.1 default got message of size 160 on Thu Jan 12 16:13:33 2006 RTM_ADD: Add Route: len 160, pid: 44, seq 23, errno 0, flags:<UP,GATEWAY,DONE,STATIC> locks: inits: sockaddrs: <DST,GATEWAY,NETMASK,IFP> default 10.10.3.1 default ppp0 got message of size 160 on Thu Jan 12 16:13:33 2006 RTM_DELETE: Delete Route: len 160, pid: 44, seq 24, errno 3, flags:<UP,CLONING,STATIC> locks: inits: sockaddrs: <DST,GATEWAY,NETMASK,IFP> base-address.mcast.net localhost 240.0.0.0 lo0 got message of size 68 on Thu Jan 12 16:13:33 2006 RTM_DELMADDR: multicast group membership removed from iface: len 68, sockaddrs: <GATEWAY,IFP,IFA> 1.0.5e.0.0.fb en0:0.11.24.36.d4.5e 224.0.0.251 got message of size 68 on Thu Jan 12 16:13:33 2006 RTM_NEWMADDR: new multicast group membership on iface: len 68, sockaddrs: <GATEWAY,IFP,IFA> 1.0.5e.0.0.fb en0:0.11.24.36.d4.5e 224.0.0.251
As you can clearly see in the bold part, the default route is deleted from our routing table, and replaced by the address of the remote network’s gateway which, unfortunately, is blocked in the remote firewall.
Fortunately, ppp has an option called “nodefaultroute” for disabling this step in the process. This is how my peer file looks:
# Disable setting the default route to this tunnel nodefaultroute # The ipparam option is passed to ip-up and ip-down scripts as the sixth parameter ipparam IA-VPN
The nodefaultroute option does exactly the same as the checkbox on Windows. We, however, are not running Windows, and can do a lot more. To show how, we pass the name of this connection on to the ip-up and ip-down scripts. There, we can use this parameter to add custom actions and logging to different connections, like I do below:
#!/bin/sh `/etc/ppp/upscripts/$6 >> /var/log/ppp-$6.log 2>&1`
#!/bin/sh `/etc/ppp/downscripts/$6 >> /var/log/ppp-$6.log 2>&1`
Now ppp will go and look for a file called IA-VPN in the upscripts and downscripts directories upon connecting and disconnecting from the virtual private natwork “IA-VPN”. Don’t forget all of these files should be owned and executable by root.
Now we can define custom routes and other actions by editing the up- and downscripts. I didn’t really need to mess with route anymore, but I liked fancy logging, so this is what I did:
#!/bin/sh # Say something interesting to demonstrate the logfile echo `date` "$0: UP"; echo `/sbin/ifconfig | grep -A 1 ppp`; # Add VPN-specific actions for bringing the connection up here
#!/bin/sh # Log the time of disconnection echo `date` " $0: DOWN"; echo; # Add VPN-specific actions for bringing the connection down here
All set! As you can see when monitoring the route table, the gateway no longer gets messed up on connecting to the VPN:
got message of size 124 on Thu Jan 12 16:07:50 2006 RTM_DELETE: Delete Route: len 124, pid: 499, seq 1, errno 0, flags:<GATEWAY,HOST,DONE,WASCLONED> locks: inits: sockaddrs: <DST,GATEWAY> eendhoven.ewi.utwente.nl 192.168.0.1 got message of size 140 on Thu Jan 12 16:07:50 2006 RTM_ADD: Add Route: len 140, pid: 499, seq 1, errno 0, flags:<UP,GATEWAY,HOST,DONE,STATIC> locks: inits: sockaddrs: <DST,GATEWAY,NETMASK> eendhoven.ewi.utwente.nl 192.168.0.1 broadcasthost got message of size 112 on Thu Jan 12 16:07:50 2006 RTM_IFINFO: iface status change: len 112, if# 7, flags:<PTP,MULTICAST> got message of size 112 on Thu Jan 12 16:07:50 2006 RTM_IFINFO: iface status change: len 112, if# 7, flags:<PTP,RUNNING,MULTICAST> got message of size 112 on Thu Jan 12 16:07:50 2006 RTM_IFINFO: iface status change: len 112, if# 7, flags:<PTP,RUNNING,MULTICAST> got message of size 80 on Thu Jan 12 16:07:55 2006 RTM_NEWADDR: address being added to iface: len 80, metric 0, flags: sockaddrs: <NETMASK,IFP,IFA,BRD> 255.0.0.0 ppp0 10.10.3.8 10.10.3.1 got message of size 124 on Thu Jan 12 16:07:59 2006 RTM_ADD: Add Route: len 124, pid: 0, seq 0, errno 0, flags:<UP,HOST> locks: inits: sockaddrs: <DST,GATEWAY> 10.10.3.1 10.10.3.8 got message of size 144 on Thu Jan 12 16:07:59 2006 RTM_ADD: Add Route: len 144, pid: 499, seq 1, errno 0, flags:<UP,DONE,STATIC> locks: inits: sockaddrs: <DST,GATEWAY,NETMASK> 10.0.0.0 ppp0 255.0.0.0 got message of size 112 on Thu Jan 12 16:07:59 2006 RTM_IFINFO: iface status change: len 112, if# 7, flags:<UP,PTP,RUNNING,MULTICAST> got message of size 68 on Thu Jan 12 16:07:59 2006 RTM_DELMADDR: multicast group membership removed from iface: len 68, sockaddrs: <GATEWAY,IFP,IFA> 1.0.5e.0.0.fb en0:0.11.24.36.d4.5e 224.0.0.251 got message of size 68 on Thu Jan 12 16:07:59 2006 RTM_NEWMADDR: new multicast group membership on iface: len 68, sockaddrs: <GATEWAY,IFP,IFA> 1.0.5e.0.0.fb en0:0.11.24.36.d4.5e 224.0.0.251
And we have nice logging of VPN activity in /var/log/ppp-IA-VPN.log:
Thu Jan 12 17:04:32 CET 2006 /etc/ppp/upscripts/IA-VPN: UP ppp0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1396 inet 10.10.3.8 –> 10.10.3.1 netmask 0xff000000 Thu Jan 12 17:05:22 CET 2006 /etc/ppp/downscripts/IA-VPN: DOWN
All of this was done on Mac OS X Tiger 10.4.4.
woei, scheelt weer een route change default :)
[…] Well, at least there is a decent way to disable using the default gateway for VPN on Mac OS X. No need to go to all that stuff I wrote about in my previous post :) […]
[…] I just figured out the equivalent checkbox in the macworld for VPN connection setup as the “Use default gateway on remote network” checkbox in windows xp. Every time I connected to my remote network using my VPN connection, my Internet connection broke, my internet stopped working. This is because my remote network uses a firewall which blocks me from using their internet connection. I was trying to change the name of my vpn connection since OS X (OSX 10.4.7) names it VPN by default and I was walking through this helpful more technical solution to the same problem which involves the name of the VPN connection. I found the equivalent checkbox for mac VPN. They must have added it since Michael wrote his article (above). Here is how to use your local internet connection while connected through the Mac OS X built in VPN connection functionality: Finder > Applications > Internet Connect > “Connect” menu > options… > “Send all traffic over vpn connection” checkbox, uncheck it. I still haven’t figured out how to rename the connection. (edit: you can’t actually rename the part that I though you could) […]
To rename a VPN, in the Internet Connection app, select VPN (PPTP), click on the configuration field which should drop down a list, choose Edit Configurations. In the configuration list, double-click the name you want to change and bingo! You can edit it.
Thanks for the ‘Default Gateway’ solutions - it’s the biggest problem I’ve had since switching to Mac.
Cheers
Chris
thanks, it was very descriptive and helpful.