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 checkbox “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).
Update: Actually, it turns out this checkbox does exist in Mac OS X and it is much easier to use than the method I describe below. See the revisit of this post for details. I have left the original method below, as some of you might find it useful.
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.
Pingback: Bas
Pingback: Michel’s Exhaust » Disabling using VPN default gateway revisited
Pingback: Academiaddict.com » Mac OS X VPN connection
Pingback: Chris McGuigan
Pingback: mamadlin
Pingback: Dog video
Pingback: Phyllis
Pingback: Nick Vanderhoven
Pingback: Michel
Pingback: Bunny
Pingback: Michel
Pingback: Brorcigow
Pingback: inockoubbibet
Pingback: jaitlyPyptoli
Pingback: MinaKetetaunc
Pingback: clantyentaiff