Setting the default gateway with TAP and DHCP

[Freddie Witherden]

Hello,

I currently have the following configuration for my server:

dev tap0
port 1194
proto udp
ca ca.crt
cert server.crt
key server.key
dh dh2048.pem

#server-bridge 10.3.14.254 255.255.255.0 10.3.14.20 10.3.14.50
server-bridge

user nobody
group nogroup
comp-lzo
persist-key
persist-tun
client-to-client
keepalive 10 120

# push "route-gateway 10.3.14.254"
# push "redirect-gateway def1"

verb 4

And on my Snow Leopard client running Tunnelblick 3.2beta28:

client
dev tap
proto udp
remote xx.xx.xx.xx 1194
resolv-retry infinite
nobind
user nobody
group nobody
persist-key
persist-tun
ca ca.crt
cert calcium.crt
key calcium.key
ns-cert-type server
comp-lzo
verb 3

The server runs a DHCP daemon. When I connect I am assigned an IP
through DHCP and the DNS is configured. The DHCP server also pushes
out a default gateway. However, although it appears in netstat:

Internet:
Destination Gateway Flags Refs Use
Netif Expire
default 192.168.2.1 UGSc 82 9
en1
default 10.3.14.254 UGScI 0 0
tap0
10.3.14/24 link#7 UCS 2 0
tap0
10.3.14.6 60:33:4b:22:26:1a UHLWI 0 0
tap0 1188
10.3.14.178 127.0.0.1 UHS 0 0
lo0
[...]

it is not used. This is presumably because 192.168.2.1 (the non-
VPN'ed default gateway) comes first. How can I fix this? If I switch
to letting OpenVPN handle the IP pools and uncomment the push
directives everything works as expected. But, letting OpenVPN handle
the IP pool is not as nice as letting my DHCP server take care of it.

Regards, Freddie.

[jkbull...gmail.com]

Although this could be a problem with Tunnelblick, I think it is more of an OpenVPN configuration question. You might want to try the OpenVPN user's forum or mailing list, or look at the OpenVPN documentation. Links to all of them are on the left side of the Tunnelblick home page.

[Freddie Witherden]

> them are on the left side of the Tunnelblick home page<http://code.google.com/p/tunnelblick/>

I had considered that it may be an issue with my OpenVPN
configuration. However, the very same config works fine on my Debian
Linux system. (Except for needing to manually run dhclient tap0 after
starting OpenVPN and dhclient wlan0 after stopping it.) It is my
understanding that on OS X Tunnelblick handles this monkey-business
and so opted to post here.

Regards, Freddie.

[jkbull...gmail.com]

OK. Please post the complete log of a connect, then disconnect sequence. (The log on the Tunnelblick VPN Details… window, not the Console log).

[Freddie Witherden]

The log follows:
2011-08-19 17:31:12 *Tunnelblick: OS X 10.6.8; Tunnelblick 3.2beta28
(build 2714); OpenVPN 2.1.4
2011-08-19 17:31:12 *Tunnelblick: Attempting connection with
Witherden; Set nameserver = 3; monitoring connection
2011-08-19 17:31:12 *Tunnelblick: /Applications/Tunnelblick.app/
Contents/Resources/openvpnstart start Witherden.tblk 1337 3 0 0 0 114
2011-08-19 17:31:13 OpenVPN 2.1.4 i386-apple-darwin10.8.0 [SSL] [LZO2]
[PKCS11] built on Jul 31 2011
2011-08-19 17:31:13 MANAGEMENT: TCP Socket listening on 127.0.0.1:1337
2011-08-19 17:31:13 Need hold release from management interface,
waiting...
2011-08-19 17:31:13 MANAGEMENT: Client connected from 127.0.0.1:1337
2011-08-19 17:31:13 MANAGEMENT: CMD 'pid'
2011-08-19 17:31:13 MANAGEMENT: CMD 'state on'
2011-08-19 17:31:13 MANAGEMENT: CMD 'state'
2011-08-19 17:31:13 MANAGEMENT: CMD 'hold release'
2011-08-19 17:31:13 NOTE: the current --script-security setting may
allow this configuration to call user-defined scripts
2011-08-19 17:31:13 PLUGIN_INIT: POST /Applications/Tunnelblick.app/
Contents/Resources/openvpn-down-root.so '[/Applications/
Tunnelblick.app/Contents/Resources/openvpn-down-root.so] [/
Applications/Tunnelblick.app/Contents/Resources/
client.down.tunnelblick.sh] [-m] [-w] [-d] [-a]' intercepted=PLUGIN_UP|
PLUGIN_DOWN
2011-08-19 17:31:13 *Tunnelblick: openvpnstart: /Applications/
Tunnelblick.app/Contents/Resources/openvpn --cd /Users/freddie/Library/
Application Support/Tunnelblick/Configurations/Witherden.tblk/Contents/
Resources --daemon --management 127.0.0.1 1337 --config /Users/freddie/
Library/Application Support/Tunnelblick/Configurations/Witherden.tblk/
Contents/Resources/config.ovpn --log /Library/Application Support/
Tunnelblick/Logs/-SUsers-Sfreddie-SLibrary-SApplication Support-
STunnelblick-SConfigurations-SWitherden.tblk-SContents-SResources-
Sconfig.ovpn.3_0_0_0_114.1337.openvpn.log --management-query-passwords
--management-hold --script-security 2 --up /Applications/
Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -m -w -d -
a --plugin /Applications/Tunnelblick.app/Contents/Resources/openvpn-
down-root.so /Applications/Tunnelblick.app/Contents/Resources/
client.down.tunnelblick.sh -m -w -d -a --up-restart
2011-08-19 17:31:13 *Tunnelblick: Established communication with
OpenVPN
2011-08-19 17:31:13 LZO compression initialized
2011-08-19 17:31:13 Control Channel MTU parms [ L:1574 D:138 EF:38 EB:
0 ET:0 EL:0 ]
2011-08-19 17:31:13 Socket Buffers: R=[42080->65536] S=[9216->65536]
2011-08-19 17:31:13 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:
135 ET:32 EL:0 AF:3/1 ]
2011-08-19 17:31:13 Local Options hash (VER=V4): 'd79ca330'
2011-08-19 17:31:13 Expected Remote Options hash (VER=V4): 'f7df56b8'
2011-08-19 17:31:13 NOTE: UID/GID downgrade will be delayed because of
--client, --pull, or --up-delay
2011-08-19 17:31:13 UDPv4 link local: [undef]
2011-08-19 17:31:13 UDPv4 link remote: xx.xx.xx.xx:1194
2011-08-19 17:31:13 MANAGEMENT: >STATE:1313771473,WAIT,,,
2011-08-19 17:31:13 MANAGEMENT: >STATE:1313771473,AUTH,,,
2011-08-19 17:31:13 TLS: Initial packet from xx.xx.xx.xx:1194,
sid=c9a1ef24 1261cdfa
2011-08-19 17:31:14 VERIFY OK: depth=1, /C=GB/ST=NA/
2011-08-19 17:31:14 VERIFY OK: nsCertType=SERVER
2011-08-19 17:31:14 VERIFY OK: depth=0, /C=GB/ST=NA/
2011-08-19 17:31:26 Data Channel Encrypt: Cipher 'BF-CBC' initialized
with 128 bit key
2011-08-19 17:31:26 Data Channel Encrypt: Using 160 bit message hash
'SHA1' for HMAC authentication
2011-08-19 17:31:26 Data Channel Decrypt: Cipher 'BF-CBC' initialized
with 128 bit key
2011-08-19 17:31:26 Data Channel Decrypt: Using 160 bit message hash
'SHA1' for HMAC authentication
2011-08-19 17:31:26 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-
AES256-SHA, 2048 bit RSA
2011-08-19 17:31:26 [server] Peer Connection Initiated with
xx.xx.xx.xx:1194
2011-08-19 17:31:27 MANAGEMENT: >STATE:1313771487,GET_CONFIG,,,
2011-08-19 17:31:29 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
2011-08-19 17:31:29 PUSH: Received control message: 'PUSH_REPLY,route-
gateway dhcp,ping 10,ping-restart 120'
2011-08-19 17:31:29 OPTIONS IMPORT: timers and/or timeouts modified
2011-08-19 17:31:29 OPTIONS IMPORT: route-related options modified
2011-08-19 17:31:29 TUN/TAP device /dev/tap0 opened
2011-08-19 17:31:29 PLUGIN_CALL: POST /Applications/Tunnelblick.app/
Contents/Resources/openvpn-down-root.so/PLUGIN_UP status=0
2011-08-19 17:31:29 /Applications/Tunnelblick.app/Contents/Resources/
client.up.tunnelblick.sh -m -w -d -a tap0 1500 1574 init
2011-08-19 17:31:31 GID set to nobody
2011-08-19 17:31:31 UID set to nobody
2011-08-19 17:31:31 Initialization Sequence Completed
2011-08-19 17:31:31 MANAGEMENT: >STATE:
1313771491,CONNECTED,SUCCESS,,xx.xx.xx.xx
No such key
2011-08-19 17:31:31 *Tunnelblick: Flushed the DNS cache
2011-08-19 17:31:34 *Tunnelblick client.up.tunnelblick.sh: Sleeping
for 0 seconds to wait for DHCP to finish setup.
2011-08-19 17:31:34 *Tunnelblick client.up.tunnelblick.sh: Sleeping
for 1 seconds to wait for DHCP to finish setup.
2011-08-19 17:31:35 *Tunnelblick client.up.tunnelblick.sh: Sleeping
for 2 seconds to wait for DHCP to finish setup.
2011-08-19 17:31:37 *Tunnelblick client.up.tunnelblick.sh: Sleeping
for 3 seconds to wait for DHCP to finish setup.
2011-08-19 17:31:40 *Tunnelblick client.up.tunnelblick.sh: Retrieved
name server(s) [ 10.3.14.254 ], domain name [ intra ], and WINS
server(s) [ ]
2011-08-19 17:31:40 *Tunnelblick client.up.tunnelblick.sh: Up to two
'No such key' warnings are normal and may be ignored
2011-08-19 17:31:40 *Tunnelblick client.up.tunnelblick.sh: Saved the
DNS and WINS configurations for later use
2011-08-19 17:31:40 *Tunnelblick client.up.tunnelblick.sh: Set up to
monitor system configuration with leasewatch
2011-08-19 17:31:46 *Tunnelblick leasewatch: A system configuration
change was ignored because it was not relevant
2011-08-19 17:32:05 event_wait : Interrupted system call (code=4)
2011-08-19 17:32:05 TCP/UDP: Closing socket
2011-08-19 17:32:05 Closing TUN/TAP interface
2011-08-19 17:32:05 PLUGIN_CALL: POST /Applications/Tunnelblick.app/
Contents/Resources/openvpn-down-root.so/PLUGIN_DOWN status=0
2011-08-19 17:32:05 PLUGIN_CLOSE: /Applications/Tunnelblick.app/
Contents/Resources/openvpn-down-root.so
2011-08-19 17:32:05 SIGTERM[hard,] received, process exiting
2011-08-19 17:32:05 MANAGEMENT: >STATE:1313771525,EXITING,SIGTERM,,
2011-08-19 17:32:05 *Tunnelblick client.down.tunnelblick.sh: Cancelled
monitoring of system configuration changes
2011-08-19 17:32:05 *Tunnelblick client.down.tunnelblick.sh: Restored
the DNS and WINS configurations
2011-08-19 17:32:06 *Tunnelblick: Flushed the DNS cache

I believe that the issue is however Tunnelblick brings up DHCP on tap0
does not put the received default gateway above the existing one in
the routing table. (Unlike dhclient on Debian.) If, after getting an
IP through DHCP, Tunnelblick could do something similar to the --route-
gateway option then things should work out -- although I am not really
that knowledgeable regarding OS X.

Regards, Freddie.

[Nicholas Williams]

Freddie, can you connect Tunnelblick to your VPN (using DHCP to push the default gateway, not OpenVPN, just like you want it to work), then execute the following command in Terminal:

$ ipconfig getpacket tap0

Then, copy the output of this command and paste it in a reply to this email?

Thanks!

Nick

[Freddie Witherden]

Sure thing:

> $ ipconfig getpacket tap0
calcium:~ freddie$ ipconfig getpacket tap0
op = BOOTREPLY
htype = 1
flags = 0
hlen = 6
hops = 0
xid = 2441313486
secs = 3
ciaddr = 0.0.0.0
yiaddr = 10.3.14.171
siaddr = 10.3.14.254
giaddr = 0.0.0.0
chaddr = aa:6:68:3a:f9:17
sname =
file = pxelinux.0
options:
Options count is 11
dhcp_message_type (uint8): ACK 0x5
server_identifier (ip): 10.3.14.254
lease_time (uint32): 0x1c20
renewal_t1_time_value (uint32): 0xe10
rebinding_t2_time_value (uint32): 0x189c
subnet_mask (ip): 255.255.255.0
broadcast_address (ip): 10.3.14.255
router (ip_mult): {10.3.14.254}
domain_name_server (ip_mult): {10.3.14.254}
domain_name (string): intra
end (none):
calcium:~ freddie

Regards, Freddie.

[Nicholas Williams]

Okay, if I understand correctly, DHCP is pushing a default gateway, and OpenVPN/Tunnelblick is setting the default gateway in the routes. But you want this gateway to take precedence over the existing default gateway on your real interface gateway, just like if redirect-gateway had been pushed by the OpenVPN server?

[Freddie Witherden]

> Okay, if I understand correctly, DHCP *is* pushing a default gateway, and
> OpenVPN/Tunnelblick *is *setting the default gateway in the routes. But you
> want this gateway to take *precedence* over the existing default gateway on

> your real interface gateway, just like if redirect-gateway had been pushed
> by the OpenVPN server?

Correct. This is what occurs on Linux and what is implied by the
OpenVPN documentation (albeit indirectly):

http://openvpn.net/index.php/open-source/faq/77-server/323-i-want-to-set-up-an-ethernet-bridge-on-the-1921681024-subnet-existing-dhcp.html
says

"The one complexity about this configuration is that you need to
modify your DHCP server configuration to differentiate between local
clients and VPN clients. The reason for this is that you must not pass
out a default gateway to VPN clients."

After asking for clarification, the reason for the last statement is
because pushing a default gateway causes all traffic to go through the
VPN (which presumably many people do not want). Hence having a DHCP
server advertise a default gateway should result in this behaviour.

Regards, Freddie.

[Jonathan K. Bullard]

This may not be relevant, but our former networking expert said that OS X behavior changed in Snow Leopard for manual settings. Perhaps this is true for the settings that Tunnelblick makes, too? The following is from The "Set Nameserver" Check Box and DNS & WINS Settings:

If you are using manual settings, different versions of OS X behave differently. This is due to a change in network behavior in Snow Leopard and is beyond the scope of this project to fix.

• If you're using Leopard (10.5) or Tiger (10.4), then it is possible to use the VPN-server-supplied DNS and WINS settings in addition to your manual settings by selecting "Set nameserver". However, your manual settings will always take precedence over any VPN server-supplied settings. If "Do not set nameserver" is selected, you will continue to use only your manually-configured settings and any VPN server-supplied settings will be ignored. "Take precedence" means that the manual DNS server will be used for all DNS queries unless it fails to answer, in which case the VPN server-supplied DNS server will be used.

• f you are using Snow Leopard (10.6), then your usual DNS and WINS settings will always be used, and no aggregation of configurations will be performed.

--
You received this message because you are subscribed to the Google Groups "tunnelblick-discuss" group.

To post to this group, send email to tunnelbli...@googlegroups.com.
To unsubscribe from this group, send email to tunnelblick-dis...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/tunnelblick-discuss?hl=en.

[Nicholas Williams]

Here's what the problem is, Freddie. Unfortunately, it boils down to being out of the control of either OpenVPN or Tunnelblick. I will try to explain it as best I can.

Different operating systems handle DHCP packets differently. While there are numerous RFC standards specifying how DHCP servers should operate and what DHCP packets should look like, the fact of the matter is that different DHCP servers include different non-standard options and omit different standard options, and different operating systems treat different options differently.

When Mac OS X (Tiger, Leopard, Snow Leopard, Lion or any of the other kitties) receives a default-gateway as part of the DHCP packet, it always sets that default-gateway as the default gateway for that interface. However, it does not allow a DHCP packet to determine which gateway is the default gateway for the entire machine. Mac OS X has a chain of precedence when it comes to which default-gateway is treated as the machine default gateway and how routes are routed:

- First, the operating system checks if the address being accessed matches a custom route in the routing table. If it does match a custom route, it always follows the gateway configured for that route, regardless of any other settings.

- Second, the default-gateway configured for the internal Ethernet card gets highest priority. If the Ethernet is installed and connected and a default-gateway is set for it, no other default-gateways are used as the machine's default gateway.

- Third, the default-gateway configured for the internal Airport card gets the next-highest priority. If the Airport card is installed and connected and a default-gateway is set for it, no other default-gateways are used as the machine's default gateway.

- Fourth, the default-gateway configured for the Firewire adapter gets the next-highest priority. If the Firewire adapter is installed, is connected to a network and a default-gateway is set for it, no other default-gateways are used as the machine's default gateway.

- Finally, any other network devices are given precedence in the order that their network configurations were received.

This may not be exact (their are lots of nuances to networking), but you get the idea. Mac OS X won't treat the default-gateway configured for your tap0 interface as the machine's default gateway, because you will always have a default-gateway configured for some other higher-priority network adapter that was connected before tap0 was.

There's little we could do about this. Technically speaking, we could make Tunnelblick treat DHCP default-gateway like OpenVPN treats the default-gateway/redirect-gateway combination (I'd have to do significant research to figure out how they did that, and Jonathan might be able to help me some there). However, this would circumvent the DHCP behavior that Apple intentionally designed, probably for a good reason.

Additionally, it would be difficult for other Tunnelblick users to disable this behavior without creating some sort of setting for it, because many DHCP servers will not let you omit a default gateway. I know mine won't (technically it will, but since my VPN adapter on my server is bridged to a local private network in that building, and that private network requires default-gateways sent to its machines, I can't disable it on the VPN network). So making this change would break users currently using Tunnelblick and DHCP and route all of their traffic through their VPNs, which many people may not intend. So, Jonathan and I will have to talk about what possible approaches we can and are willing to take, and update you later.

With that said, I must ask why you need to route all of you traffic through your VPN? If you go to Google to perform a search, do you really want that traffic first needlessly diverted to your VPN server? This would only server to slow down that traffic and increase CPU and network utilization for your VPN server.

[jkbull...gmail.com]

Thanks, Nick -- that was such a great explanation that I think even I understood it :-)

And it explains to me why if I have Ethernet and Airport both connected, OS X uses Ethernet. (I always wondered about that.)

Question: Can Freddy achieve the effect he wants by using OpenVPN's "-redirect-gateway def1" option?

If that won't work because OpenVPN doesn't know the gateway until after DHCP sets it, customized up/down scripts could use routing to emulate the option. The customized the up script knows the gateway, since it waits until the settings have been established by DHCP before finishing. The routing would take precedence over everything, as Nick's first bullet point describes.

"-redirect-gateway def1" is described on

http://www.openvpn.net/index.php/open-source/documentation/manuals/427-openvpn-22.html

[Freddie Witherden]

On Aug 25, 2:17 pm, Nicholas Williams <nicho...@nicholaswilliams.net>
wrote:

> When Mac OS X (Tiger, Leopard, Snow Leopard, Lion or any of the other

> kitties) receives a default-gateway as part of the DHCP packet, it *always* sets
> that default-gateway as the default gateway *for that interface*. However,

> it does not allow a DHCP packet to determine which gateway is the default

> gateway *for the entire machine*. Mac OS X has a chain of precedence when it

> comes to which default-gateway is treated as the machine default gateway and
> how routes are routed:
>
> - First, the operating system checks if the address being accessed matches a

> custom route in the routing table. If it does match a custom route, it *
> always* follows the gateway configured for that route, regardless of any

> With that said, I must ask *why* you need to route *all* of you traffic

> through your VPN? If you go to Google to perform a search, do you really
> want that traffic first needlessly diverted to your VPN server? This would
> only server to slow down that traffic and increase CPU and network
> utilization for your VPN server.

Thank you for this explanation (OS X networking is not my forte)!
However, one of the more interesting nuances is what Apple themselves
do. When you connect to an PPTP or LT2P/IPSEC VPN (using the Apple
configuration dialogue) a ppp adapter is created as opposed to a tap.
The Apple configuration dialogue provides an option for deciding if
you want to route all traffic through the VPN. If you select this,
the ppp0 adapter appears first in the default routing table. How they
do it I am unsure, it probably uses a similar brand of voodoo to
OpenVPN + redirect-gatewat def1. So, having an option for this might
not be a bad thing (tm) -- after all Apple decided it was an
acceptable option for their own VPN config.

As for why all traffic needs to be routed through a VPN. Firstly, I
often connect to unsecured wireless networks at coffee shops and the
such. Given that I can not trust the network it is important that
traffic be encrypted. Too much of the web is not https.

Secondly, many academic journals implement IP-based access control.
If I am not on my colleges network range I don't get access. To solve
this issue my college provides a VPN which lets me tunnel into their
network. But for it to work (these journals are online websites) I
really need everything to go through the VPN. The less hassle, the
better.

As for --redirect-gateway defl1. I did play about with it. My plan
was to use --route-delay to get OpenVPN to wait a bit (giving time for
DHCP to do its job) but sadly had no luck as OpenVPN did not know what
gateway to set and attempting to manually specify the gateway did not
work either.

Regards, Freddie.

[jkbull...gmail.com]

I understand why Freddy wants everything to go through the VPN -- it is a very common requirement. It may even be what most VPN setups do.

But I don't think it is Tunnelblick's role -- as a GUI for OpenVPN -- to offer that option, it's OpenVPN's.

And OpenVPN offers the -redirect-gateway option to do it. In my view it's a bug (or more gently, a missing feature) for OpenVPN to not be able to implement -redirect-gateway in Freddy's particular setup.

I think Tunnelblick does offer a way to do what Freddy wants, with customized up/down scripts, as I described in my prior post.

There are several ways to use custom up/down scripts. The easiest is to create a Tunnelblick VPN Configuration which includes "up.tunnelblick.sh" and "down.tunnelblick.sh". The scripts themselves should be customized versions of the standard scripts, which are "client.up.tunnelblick.sh" and "client.down.tunnelblick.sh" (both contained in Tunnelblick.app/Contents/Resources). See Using Scripts for details.

A side note about your client configuration:

There is a unadvertised catch to having the client configuration include "user nobody / group nobody" -- if OpenVPN (as opposed to the up/down scripts) does any routing, the connection can't be restarted properly because OpenVPN can't restore the routes as part of the restart process because it isn't running as root. The way around that is to put all routing in -- guess what? -- customized up/down scripts. If openvpn-down-root.so is used, the scripts will run as root and thus can manipulate the routes. I would recommend removing the user/group options to get things set up the way you want, then add them and see what needs to be done to make them work.

[Freddie Witherden]

On Aug 25, 3:33 pm, "jkbull...gmail.com" <jkbull...@gmail.com> wrote:
> But I don't think it is Tunnelblick's role -- as a GUI for OpenVPN -- to
> offer that option, it's OpenVPN's.
>
> And OpenVPN offers the -redirect-gateway option to do it. In my view it's a
> bug (or more gently, a missing feature) for OpenVPN to not be able to
> implement -redirect-gateway in Freddy's particular setup.

I'm on the fence there. I think the OpenVPN developers could quite
rightly claim that it is the job of the DHCP client to handle the
routing table when server-bridge is used standalone. The problem
appears to be that the DHCP client of OS X handles things
differently. For -- probably very good -- reasons OpenVPN developers
have decided not to handle "--route-gateway dhcp" on OS X and Linux.

> I think Tunnelblick does offer a way to do what Freddy wants, with
> customized up/down scripts, as I described in my prior post.
>
> There are several ways to use custom up/down scripts. The easiest is to

> create a Tunnelblick VPN Configuration<http://code.google.com/p/tunnelblick/wiki/cConfigT> which

> includes "up.tunnelblick.sh" and "down.tunnelblick.sh". The scripts
> themselves should be customized versions of the standard scripts, which are
> "client.up.tunnelblick.sh" and "client.down.tunnelblick.sh" (both contained

> in Tunnelblick.app/Contents/Resources). See Using Scripts<http://code.google.com/p/tunnelblick/wiki/cUsingScripts> for
> details.

Yes, I am in no doubt that the up and down .sh scripts are the place
to do this. With the potential complication of determining when DHCP
has assigned an IP to the interface it should just be a case of
setting up a static route to the current default gateway through the
existing interface and then removing the current default gateway.
(This is similar to what --redirect-gateway def1 does except that it
will add the VPN server as a default gateway, which we do not need
to.)

If I -- or someone more knowledgeable than myself -- were to write
such up/down scripts to perform this would it be possible to have them
included in the default configuration? An argument could be used to
allow Tunnelblick to provide a UI option for this (disabled by
default, naturally).

> A side note about your client configuration:
>
> There is a unadvertised catch to having the client configuration include
> "user nobody / group nobody" -- if OpenVPN (as opposed to the up/down
> scripts) does any routing, the connection can't be restarted properly
> because OpenVPN can't restore the routes as part of the restart process
> because it isn't running as root. The way around that is to put all routing
> in -- guess what? -- customized up/down scripts. If openvpn-down-root.so is
> used, the scripts will run as root and thus can manipulate the routes. I
> would recommend removing the user/group options to get things set up the way
> you want, then add them and see what needs to be done to make them work.

Thank you for this. The user/group advice does seem to be given out
blindly in client/server configs.

Regards, Freddie.

P.S. If you want your AirPort to come before your ethernet adapter
when it comes to the default route all you need to do is go to the
network preference pane, click the cog and go "Set service order".

[jkbull...gmail.com]

I don't think I would include such custom scripts to Tunnelblick. The scripts included in Tunnelblick are for only the most common setups.

If you were to develop customized scripts that do that, it would be great if you would let me add them to the User-Contributed section of the download page, so that anyone who does need them could benefit from them.

Thanks for the PS, too -- I had forgotten about that.

[Nicholas Williams]

First, thanks for the "Set service order" option information. I didn't even know it exists.

Alright, here's what I think, after reading your opinions:

The root problem here is that OpenVPN takes care of DHCP in other operating systems, but does not take care of DHCP in Mac OS X. That's the reason I got so involved in Tunnelblick: to contribute to it so that I could add DHCP support for Mac OS X. If we were to follow this goal to its natural conclusion, it would make sense that Tunnelblick would attempt to naturally emulate OpenVPN in other operating systems as closely as possible.

Then, there's the built-in VPN options in Mac OS X (which I have never personally used). Freddie's right, Mac OS X does let you say "Route all traffic through this VPN." It also makes sense to me that Tunnelblick should, where possible, try to (as closely as possible) replicate the behavior of the built-in Mac OS X networking utilities. If they have the option to route all traffic through the VPN, it makes sense that Tunnelblick could have that option, too.

Here's what I recommend: right now the Set DNS/WINS options in Tunnelblick are "Set nameserver", "Set nameserver (3.1)", "Set nameserver "3.0b1" and "Set nameserver (alternate 1)." Other than "Set nameserver," I don't know which ones are intended to remain when 3.2 is released non-beta. What I do know is that "Set nameserver" is the one I wrote, and it's the one that takes care of DHCP options.

I propose we create a new script called "Set nameserver + default gateway" that is identical to "Set nameserver" except that it makes the gateway assigned by DHCP the default machine gateway just like the other VPN options in Mac OS X. If the OpenVPN server does NOT push DHCP, then "Set nameserver" and "Set nameserver + default gateway" behave identically, because "Set nameserver + default gateway" is only concerned with the default gateway pushed by DHCP.

I can easily determine whether DHCP is pushing a default gateway, that is not the issue. I do not yet know how to move that gateway up to the top (although it can certainly be done, as we have obviously seen). I estimate that within the next week I should be able to find the time to solve that problem and get a new script written that uses the default gateway.

Freddie, I welcome you to search for what methods one can use to reorder default gateways in Mac OS X. That will help speed things along.

Jonathan, what do you think about this solution? It's your baby, so it's your call, but from my perspective I think it improves the product.

[jkbull...gmail.com]

Thanks, Nick for the offer. Let me step back a bit: This subject came up because Freddie wants to use his DHCP servers and redirect all traffic through the VPN, and Tunnelblick/OpenVPN on OS X doesn't do that.

Up until now, I did not consider it necessary to offer a "Route all traffic through the VPN" option, since it would just duplicate what OpenVPN can do with the "-redirect-gateway" option. Appparently I was wrong: -redirect-gateway" doesn't work with DHCP. (Or this way of using DHCP, anyway).

Could the script fiddle things so that "-redirect-gateway" works properly, even with this DHCP setup? By, essentially, emulating what OpenVPN does (which I think is by adding routes, not "moving that gateway up to the top").

In other words, the standard script does this fiddling if and only if it's using HDCP and the "-redirect-gateway" is present -- and according to the  "-redirect-gateway" flags -- not because it is a separate script or an option for the standard script?

Would that work?

[Nicholas Williams]

In theory, this might be possible. But I foresee two problems:

The first problem is that OpenVPN can't just say "redirect-gateway." It has to say "default-gateway x.x.x.x" (different from the DHCP "default-gateway") and then it has to define the gateway to redirect to with "redirect-gateway def1" (at least, that's my understanding of it). If you put this on the server end and push it, you have to make sure they always say the same thing (otherwise, which is Tunnelblick to use?). If you put this on the client configuration (because you're connecting to a VPN server you don't have control over, such as at a college), then it will quit working if the gateway address ever changes (which could happen often in some cases).

The second problem is that I don't know how OpenVPN clients on other operating systems will react to receiving a default gateway pushed from DHCP and a default-gateway/redirect-gateway pushed from OpenVPN.

It could certainly be investigated further, but I'm afraid by going down that route we might be opening a can of worms.

I plan on routing the traffic the same way OpenVPN does, whether that's by moving up the default route or adding another route (I don't know yet; I'll have to experiment). However, I think relying on the DHCP information alone to decide when to route the traffic through the VPN is the better plan. I'm open to discussion, of course.

Nick

[Jonathan K. Bullard]

Thanks, Nick -- every email you send helps me understand more. (Or maybe I just think I'm understanding more :-)

I had been looking at it in terms of "-redirect-gateway", but as I now understand it, if DHCP supplies a default gateway right now, we in effect ignore it. What we should do is route all traffic through it -- it should override both the existing default gateway and the VPN gateway (if necessary).

(We don't really ignore the DHCP-supplied default gateway: the script dutifully tells OS X about it. But OS X in effect ignores it, as Nick described.)

Isn't ignoring a DHCP-supplied default gateway a bug?

If so, why can't we work around it in the standard scripts? That is, not make a new, optional script that does the correct thing, but instead, put a workaround into the standard script.

The standard script would change so that if DHCP supplied a gateway, all traffic would go through the DHCP-supplied (VPN) gateway, even though redirect-gateway is NOT specified.

If DHCP did not supply a gateway, the standard script wouldn't do anything differently -- only VPN traffic would go through the VPN gateway, and other traffic would go through the (pre-DHCP) default gateway.

There would still be a problem if both a DHCP-supplied default gateway and a "redirect-gateway" were specified but conflicted -- we would be ignoring the "redirect-gateway". To me that's OK because we can't do both. But I would consider that a configuration error -- specifying conflicting settings-- so I'm not terribly concerned about it. It would be nice to detect and complain about it, but that may be hard to do.

Of course there's always a chance that people are relying on the "bug" -- Is that why you want to make it a separate script?

--

You received this message because you are subscribed to the Google Groups "tunnelblick-discuss" group.

To view this discussion on the web visit https://groups.google.com/d/msg/tunnelblick-discuss/-/Kh70pv3cfeUJ.

[Freddie Witherden]

Hi Jonathan,

The problem is quite a subtle one. When using a TAP an OpenVPN server
can act in one of two modes. The first I like to call pseudo-DHCP and
is when one specified --server-bridge <ip range>. In this case
OpenVPN handles configuring an IP address for the clients TAP using
ifconfig and friends. When using this mode two additional directives
are also available --route-gateway to tell OpenVPN what gateway
clients should configure the TAP with and --redirect-gateway to make
this the default gateway. In this mode OpenVPN does everything and so
it all works as expected.

The second mode is when OpenVPN does no IP configuration on the TAP
whatsoever and instead specifies "--route-gateway dhcp" to clients.
On GNU/Linux and Mac OS X this is effectively a no-op. To work around
this the current Tunnelblick scripts ask OS X to go and use DHCP to
configure the TAP. The quirk is this: the OS X DHCP client does not
insert default gateways it receives to the top of the routing table.
(It instead uses on OS defined order.)

For /some/ people this is precisely the behavior they want (that is to
say that not all traffic flows through the VPN). However, technically
speaking it is a 'bug' -- albeit one that people rely on. While
another script is a fine solution equally valid is a command line
argument to the existing scripts specifying how to handle TAP/DHCP
gateways.

The one issue when modifying this existing scripts is one of state.
If we remove the existing default gateway (like --redirect-gateway
def1 does in OpenVPN) we need to somehow be able to restore it when
the VPN is terminated. How best to go about this I am unsure.

Regards, Freddie.

[Nicholas Williams]

Jonathan/Freddie,

I don't know that I'd even call it a bug. Mac OS X very intentionally designs their network structure that way. And I know that I DO NOT want all of my traffic routed through my VPN. However, my DHCP server DOES send a default gateway, and I can't change that (because my networks are bridged). So, we can't just change the standard scripts to always route all traffic through the VPN if the DHCP server sends a default gateway. I would wager that more people do NOT want that behavior than that DO, and I'm one of the ones that does not.

No, there definitely needs to be some way to to tell Tunnelblick "yes, I do want all my traffic routed through the VPN" or "no, I do not" if the DHCP server provides a default gateway.

Nick

[Jonathan K. Bullard]

OK -- thanks to both of you -- Nick and Freddie -- for educating me about this. I know it's been a struggle but I think you've managed to drum it into my head!

Here's what I propose:

• Integrate this behavior into the standard scripts, with an option to the scripts specifying this behavior.
• Add a checkbox to control it in the 'Advanced' window of the 'Settings' tab.

Reasoning:

• I want to integrate this into the standard scripts so there is only one "current" script (all the other scripts are there only for backward compatibility);
• I don't want to clutter the 'Settings' tab with another choice; and
• I want the user to be able to modify it form the GUI.

Normally, the behavior would be as it is now. To get the new behavior:

• The user would have to put a check in the checkbox; or
• The person distributing Tunnelblick or the configuration would need to:
• Use a "Deployed" version of Tunnelblick which forces the preference controlling this; or
• Use a Tunnelblick VPN Configuration with an Info.plist that contains the preference controlling this.

Since all settings in Tunnelblick are preferences, it would be a per-configuation preference named 'XXXXX-forceGatewayIfTapAndGatewayFromDHCP' or something similar. (XXXXX would be replaced with the name of the configuration, as in all similar preferences.)

Does this make sense to the two of you?

Would "Set default gateway from DHCP over tap" be a good name for the checkbox?

Thanks again,

-- Jon

--

You received this message because you are subscribed to the Google Groups "tunnelblick-discuss" group.

To view this discussion on the web visit https://groups.google.com/d/msg/tunnelblick-discuss/-/HVvubiyjbXsJ.

[Nicholas Williams]

I'm good with that solution. A checkbox most closely mimics the way the OS does it for "supported" VPNs. 

For the checkbox text, I would go with "Send all traffic over VPN if DHCP pushes default gateway." It's more exact and very clear in what it does and when it doesn't do anything (checking it has no effect if DHCP doesn't push a default gateway). It's also worded nearly identical to how the OS words the setting for "supported" VPNs.

The only other thing we need to consider is conflicts. What if the user has two or more VPNs configured with that checkbox checked? Obviously it can't work for all of them. What do we do then?

Nick

[Jonathan K. Bullard]

Thanks for your comments, Nick, they're very helpful.

 

For the checkbox text, I would go with "Send all traffic over VPN if DHCP pushes default gateway." It's more exact and very clear in what it does and when it doesn't do anything (checking it has no effect if DHCP doesn't push a default gateway). It's also worded nearly identical to how the OS words the setting for "supported" VPNs.

My problem with that is that it sounds like it should apply to more situations than it really does. It sounds like it applies to my home network, for example, which uses DHCP to push a default gateway to my computer (nothing to do with VPNs). When I make a tun connection that doesn't include "-redirect-gateway def1", all traffic is NOT sent over the VPN, so I would have a false sense of security, thinking everything is going through the VPN.

I'd rather have something that sounds a bit more technical, so it scares someone into leaving it alone or look into it further (maybe via the help button - the help can have a more detailed explanation that will clarify when this checkbox applies). I don't want someone to think "Oh, that will send everything over the VPN", put a check in the checkbox, and think they're sending everything over the VPN.

I would love to have a checkbox that said "Send all traffic over the VPN", but I don't think I can do that:

• If the checkbox is checked, I can open OpenVPN with a command-line-option of "-redirect-gateway def1"; but
• If the checkbox is NOT checked, I can't make OpenVPN ignore a "-redirect-gateway" in the configuration file or pushed from the server. (At least I don't think I can.)

The only other thing we need to consider is conflicts. What if the user has two or more VPNs configured with that checkbox checked? Obviously it can't work for all of them. What do we do then?

There won't be a conflict having the checkboxes checked simultaneously because, in effect, there is a different checkbox for each configuration. (The 'Settings' tab and the 'Advanced' window always refer to the currently-selected configuration in the 'VPN Details…' window.)

If there are two or more configurations with the checkbox checked being connected simultaneously, Tunnelblick could/would detect that and warn about it, letting the user proceed or cancel. This involve adding to the window that appears when you have two simultaneous connections -- see the attached screenshot. It would add info about the # of configurations with the checkbox checked.

Unfortunately, I don't see a way for Tunnelblick to know if having the checkbox checked actually accomplishes anything because it depends on whether or not the VPN's DNS server sends the default gateway, which isn't known until after the connection has been established. (So I would probably only show the extra information if more than one of the simultaneous connections had the checkbox checked.)

- Jon

[Freddie Witherden]

On Aug 26, 8:07 pm, Nicholas Williams <nicho...@nicholaswilliams.net>
wrote:

> The only other thing we need to consider is conflicts. What if the user has
> two or more VPNs configured with that checkbox checked? Obviously it can't
> work for all of them. What do we do then?

Actually, I can. Lets say I have two TAP/DHCP VPNs and on both have
opted for the default gateway to be used. Let these be VPN A at
4.4.4.4 and VPN B at 8.8.8.8. Also let my current gateway be
192.168.0.1.

I connect to A. tap0 is created and gets an IP. A gateway of 4.4.4.4
is pushed. Our scripts do their thing and the topmost default gateway
is 4.4.4.4 on tap0.

I connect to B. OpenVPN uses the default gateway (now 4.4.4.4) to
connect to 8.8.8.8 -- creating tap1 in the process. A gateway of
8.8.8.8 is pushed and our scripts do their thing. We now have a
topmost gateway of 8.8.8.8 on tap1.

The result is a VPN-over-a-VPN. Sometimes this is what you want
(namely if 8.8.8.8 only accepts connections from 4.4.4.4 -- I've seen
it). The most elegant way to handle this, IMO, is upon connecting to
a VPN we check to see that if it is set to redirect the gateway *and*
we are already connected to a VPN which does the same then to show a
warning dialogue. In this we can explain that it would result in a
tunnel-over-a-tunnel and if they would like to temporarily disable the
redirect option or continue anyway.

It is perhaps worth highlighting the connecting to two regular (either
plain IP routed tun or non-DHCP tap) VPNs with "--redirect gateway
def1" pushed would result in the same behavior as that described
above.

Regards, Freddie.

P.S. For those getting here because they are wondering how to stop
their DHCP server pushing default gateways for VPN traffic. iptables
physdev is your friend.

[Jonathan K. Bullard]

The most elegant way to handle this, IMO, is upon connecting to

a VPN we check to see that if it is set to redirect the gateway *and*
we are already connected to a VPN which does the same then to show a
warning dialogue.  In this we can explain that it would result in a
tunnel-over-a-tunnel and if they would like to temporarily disable the
redirect option or continue anyway.

That might be best, but I think it is too complicated to do for a situation that doesn't come up very often. We don't know if a connection will do this or not until the up script sees if DHCP pushed a default gateway. That's long after the user clicked "Connect".

The second connection's up script is the only one that knows that it is doing this, and it doesn't know that the first one already did it. Tunnelblick knows about the settings, but doesn't know for sure that the settings will result in DHCP pushing a default gateway. To create a mechanism for scripts to pass information to each other or Tunnelblick for this situation seems like a lot of work for little reward.

I think it has to be up to the person who set a computer up to use two VPNs simultaneously to set them up properly -- there are a lot of misconfigurations that Tunnelblick could diagnose, but doesn't. It isn't a VPN-configuration-checking tool!

 

It is perhaps worth highlighting the connecting to two regular (either
plain IP routed tun or non-DHCP tap) VPNs with "--redirect gateway
def1" pushed would result in the same behavior as that described
above.

I'm don't think redirect-gateway works that way. When I have seen it on single tun connections, it works the way that the OpenVPN man page says it does -- by setting routes. My understanding is that those routes apply to all interfaces (which is why it works).

[Nicholas Williams]

I see the confusion with my suggestion: which DHCP are we talking about? However, I don't think "Set default gateway from DHCP over tap" quite cuts it, either. It's technical, yes, but it's inaccurate: the default gateway is already being set right now. We're not worried about setting the default gateway (Mac OS X has multiple default gateways, remember). We're worried about making the default gateway be used to route all traffic. This is different. How about, "Send all traffic over VPN if VPN-DHCP pushes default gateway"? That is exact, somewhat technical and (I believe) makes it clear that we're talking about the DHCP from the VPN and not your local DHCP (or any other DHCP).

I wouldn't worry about trying to start OpenVPN with "-redirect-gateway". That starts making things very complicated.

Also, I agree with Jonathan: there are lots of ways to screw up an OpenVPN configuration. Tunnelblick can't check for all of them. We make it clear in help that this is a dangerous option that can slow down all of you traffic, and we make it clear that it's even more dangerous if you connect to multiple VPNs simultaneously that all have that option checked. And we leave it at that.

[Nicholas Williams]

Also, Jonathan, I need to figure out what OpenVPN does to routes to make redirect-gateway work in Mac OS X. Do you have a VPN set up (or know of a secure one you use for testing) that I could use for inspecting the routes made?

[Jonathan K. Bullard]

"Send all traffic over VPN if VPN-DHCP pushes default gateway" looks good to me.

Here's what a typical Tun VPN (the free Arethusa VPN) does when there is no redirect-gateway (after running the up script):

2011-08-26 18:57:43 /sbin/route add -net 10.17.0.1 10.17.0.205 255.255.255.255

                                        add net 10.17.0.1: gateway 10.17.0.205

2011-08-26 18:57:43 Initialization Sequence Completed

Here's what it does with "redirect-gateway def1"

and with"redirect-gateway def1 bypass-dhcp"

and with"redirect-gateway def1 bypass-dhcp bypass-dns" (i.e., all three give identical results, as far as I can see):

2011-08-26 18:53:38 /sbin/route add -net 88.191.121.143 <<<my LAN gateway>>> 255.255.255.255

                                        add net 88.191.121.143: gateway <<<my LAN gateway>>>

2011-08-26 18:53:38 /sbin/route add -net 0.0.0.0 10.17.0.165 128.0.0.0

                                        add net 0.0.0.0: gateway 10.17.0.165

2011-08-26 18:53:38 /sbin/route add -net 128.0.0.0 10.17.0.165 128.0.0.0

                                        add net 128.0.0.0: gateway 10.17.0.165

2011-08-26 18:53:38 /sbin/route add -net 10.17.0.1 10.17.0.165 255.255.255.255

                                        add net 10.17.0.1: gateway 10.17.0.165

(88.191.121.143 public IP of the Arethusa OpenVPN server)

I believe that it is the two bold commands that cause everything to go through the VPN (which is what the OpenVPN man page says it does) and that the command above them makes sure that the server can still be accessed directly. Apparently bypass-dhcp and bypass-dns don't do anything.

Using "redirect-gateway" without any arguments produces:

2011-08-26 19:34:15 /sbin/route add -net 88.191.121.143 192.168.125.1 255.255.255.255

                                        add net 88.191.121.143: gateway <<<my LAN gateway>>>

2011-08-26 19:34:15 /sbin/route delete -net 0.0.0.0 <<<my LAN gateway>>> 0.0.0.0

                                        delete net 0.0.0.0: gateway <<<my LAN gateway>>>

2011-08-26 19:34:15 /sbin/route add -net 0.0.0.0 10.17.0.5 0.0.0.0

                                        add net 0.0.0.0: gateway 10.17.0.5

2011-08-26 19:34:15 WARNING: potential route subnet conflict between local LAN [10.17.0.0/255.255.255.0] and remote VPN [10.17.0.1/255.255.255.255]

2011-08-26 19:34:15 /sbin/route add -net 10.17.0.1 10.17.0.5 255.255.255.255

                                        add net 10.17.0.1: gateway 10.17.0.5

I've never seen any configurations that used "redirect-gateway" without def1, by the way. Maybe people avoid it because the OpenVPN man page says "Using the def1 flag is highly recommended."

[Jonathan K. Bullard]

It is perhaps worth highlighting the connecting to two regular (either
plain IP routed tun or non-DHCP tap) VPNs with "--redirect gateway
def1" pushed would result in the same behavior as that described
above.

I don't think that is correct, because of the way that "-redirect-gateway" is implemented -- by routing commands, not by setting default gateways. The routing commands that implement "-redirect-gateway" apply to all interfaces, not a particular interface.

At first I thought that all traffic would be sent through whatever VPN last made a connection. So if VPN A is connected, then VPN B (both with "-redirect-gateway"), everything would go through VPN B.

However, I just tried this, and the "-redirect-gateway" routing commands when the second VPN was established (VPN B) were not accepted, so everything continued to route through VPN A. The relevant log entries were:

2011-08-27 06:21:46 /sbin/route add -net 0.0.0.0 10.17.0.169 128.0.0.0

                                        route: writing to routing socket: File exists

                                        add net 0.0.0.0: gateway 10.17.0.169: File exists

2011-08-27 06:21:46 /sbin/route add -net 128.0.0.0 10.17.0.169 128.0.0.0

                                        route: writing to routing socket: File exists

                                        add net 128.0.0.0: gateway 10.17.0.169: File exists

So it appears that all traffic will go through whatever VPN is established with "-redirect-gateway" first. (By "all traffic", I mean all traffic that is not specifically directed to a VPN.)

Then I tried establishing VPN A, then VPN B, then disconnecting VPN A. As expected, that resulted in all traffic going through my normal Internet connection -- not through either VPN. (Again, by "all traffic", I mean all traffic that is not specifically directed to a VPN.)

So it looks like "-redirect-gateway" does what the documentation says it does, and redirects all traffic, not just traffic for a particular interface.

I think this means that we can't use the same mechanism as "-redirect-gateway" to implement the "set default gateway from DHCP" so as to allow the "VPN-over-a-VPN" described by Freddie.

It also may mean that, if we do implement it differently, we can't name the checkbox "Send all traffic over VPN if VPN-DHCP pushes default gateway".

Is this becoming too complicated and messy to do for such an unusual case? Maybe we should leave it up to whoever sets up the network/VPN to do it themselves. Tunnelblick provides a rich set of scripting abilities in addition to the up/down scripts provided by OpenVPN.

[Nicholas Williams]

I don't have a lot of time right now, because I'm on the road. But I think your making this more complicated than it has to be. 

With redirect-gateway, OpenVPN can't set a route for 0.0.0.0-255.255.255.255 because OS X translates that to "default for the machine." I learned this the hard way yesterday when I tried this technique and it essentially made my Internet connection unusable. I had to restart. 

So OpenVPN creates, in order of priority, a route for the VPNs IP address pointing to the gateway it connected through, then a route for 0.0.0.0-127.255.255.255 pointing to the VPN gateway, then a route for 128.0.0.0-255.255.255.255 pointing to the VPN gateway. This routes all traffic through the VPN, except the traffic TO that VPN server, which is routed through the default route. 

The second VPN connection will HAVE to connect through the first VPN; it's IP address is different, thus the routing tables demand it. When the two fake default routes are attempted, they will fail to create because of a uniqueness constraint. The result being that ALL traffic, including traffic for the second VPN, will be routed through the first VPN. However, all traffic will NOT be routed through the second. When you disconnect, naturally all traffic is re-routed through the machine's default gateway. 

I don't think we should be trying to implement this any particular way other than the way OpenVPN implements it for redirect-gateway. This means A) we can still name the checkbox that and B) we need to say in the help that if you connect to multiple VPNs with that option checked, "all traffic" will only be routed through the first VPN. I just don't foresee this being anything close to a common situation; I'd be surprised if it ever happens. 

It may be a little complicated, but I wouldn't call it messy. ;)

Nick

Sent from my iPhone

--

You received this message because you are subscribed to the Google Groups "tunnelblick-discuss" group.

[Jonathan K. Bullard]

I don't think we should be trying to implement this any particular way other than the way OpenVPN implements it for redirect-gateway. This means A) we can still name the checkbox that and B) we need to say in the help that if you connect to multiple VPNs with that option checked, "all traffic" will only be routed through the first VPN. I just don't foresee this being anything close to a common situation; I'd be surprised if it ever happens. 

Hmmm. Then we wouldn't be doing what other implementations do (Windows, anyway).

And if we have the checkbox, people will start asking why they can't have a checkbox that redirects for ALL configurations. But that's a real pain to do, because if the checkbox isn't checked but OpenVPN did "-redirect-gateway" we'd need to remove the fake routing that OpenVPN set, which is hard because OpenVPN sets it after our up script has finished.

It may not be worth doing, then - let the network admin or whoever sets up the VPN configuration specify how it should work, using custom scripts if necessary.

[Nicholas Williams]

I'm confused now lol. How do other implementations do redirect-gateway that's different from how redirect-gateway works on Mac OS X?

I just don't think you're going to see anyone asking for VPN-over-VPN-over-VPN-over... It's just not gonna be a common thing. Remember that this checkbox is only for "if VPN-DHCP pushes default gateway." If they're using DHCP, OpenVPN won't use redirect-gateway, so we don't have to worry about it. If they're not using DHCP, the checkbox is meaningless because of the wording, so again we don't have to worry about it. And if there's ever any confusion, the help item for it will describe exactly when it does and doesn't have an impact on the network configuration. 

You said yourself that it's fairly common for people to want to route all traffic through the VPN. Shouldn't we try to support that?

Nick

Sent from my iPhone

[Freddie Witherden]

I think the issue with the checkbox can be solved by simply negating it.  Rather than something along the lines of "redirect all traffic over the VPN if using TAP/DHCP" we should instead say "Ignore default gateways from DHCP services" and have it checked by default.

As for implementation: it is *much* better to have gateway redirection work -- but only for one VPN -- than it is for it not to work at all.  Sure VPN-over-VPN-... would be nice, but it is far from essential.

Regards, Freddie.

[Jonathan K. Bullard]

I'm confused now lol. How do other implementations do redirect-gateway that's different from how redirect-gateway works on Mac OS X?

I've been confused for this whole discussion lol!

Sorry I wasn't clear (and maybe I still don't get it).

What I meant was that the original problem was that we don't do what Linux does:

> Okay, if I understand correctly, DHCP *is* pushing a default gateway, and > OpenVPN/Tunnelblick *is *setting the default gateway in the routes. But you > want this gateway to take *precedence* over the existing default gateway on > your real interface gateway, just like if redirect-gateway had been pushed > by the OpenVPN server? Correct.  This is what occurs on Linux and what is implied by the OpenVPN documentation (albeit indirectly):

If we mimic "-redirect-gateway", we still won't be doing what Linux does, because Linux allows (I gather) VPN-over-VPN-over-VPN. So we'll solve the problem for some situations, but not others.

I just don't think you're going to see anyone asking for VPN-over-VPN-over-VPN-over... It's just not gonna be a common thing. Remember that this checkbox is only for "if VPN-DHCP pushes default gateway." If they're using DHCP, OpenVPN won't use redirect-gateway, so we don't have to worry about it. If they're not using DHCP, the checkbox is meaningless because of the wording, so again we don't have to worry about it. And if there's ever any confusion, the help item for it will describe exactly when it does and doesn't have an impact on the network configuration. 

You said yourself that it's fairly common for people to want to route all traffic through the VPN. Shouldn't we try to support that?

Yes. OpenVPN implements "route all traffic through the VPN" when "-redirect-gateway" is specified. Freddie tried to use a different mechanism to do it that works on Linux (and Windows?) but it didn't work on OS X.

I originally thought "-redirect-gateway" wouldn't work with Freddie's setup, because I assumed OpenVPN sets the routing to implement "-redirect-gateway" before the up script is run (so it can't use the DHCP-supplied default gateway which is set in the up script).

But I was wrong about that: having experimented (see the log extracts in the above posts), OpenVPN does the routing after the up script, so OpenVPN should be able to use the correct default gateway.

If "-redirect-gateway" doesn't work, why doesn't it? That would be worth investigating.

If "-redirect-gateway" does work, why not just tell people to use it, which is what we tell everyone else? Or, if they want VPN-over-VPN-over-VPN, they can use a custom script (which they'll need to do even if we implement this).

It would be great to have a checkbox "Send all traffic through the VPN" and have it control "-redirect-gateway". But that looks hard without a '-redirect-gateway off" OpenVPN option.

========

"Ignore default gateways from DHCP services" implies that if it is not checked, we don't ignore them, and although we don't ignore them, we still don't do what Linux does -- we do something similar.

[Freddie Witherden]

Rather than trying to do what OpenVPN does with redirect-gateway def1
(adding static routes that encompass all of the IPv4 address space bar
127.x.x.x) we should just remove the current default gateway.

I mean, we currently have:
default <existing default gateway>
default <VPN gateway from DHCP>

so, why do we not just do what OS X does when it connects to a VPN
with traffic redirection enabled. The following was captured from
route monitor (ic.ac.uk is my college VPN, 10.3.14.254 = lithium = my
existing default gateway, 10.3.14.1 = calcium, my mac):

calcium:Programming freddie$ route monitor

got message of size 140 on Sat Aug 27 22:35:22 2011
RTM_DELETE: Delete Route: len 140, pid: 7342, seq 1, errno 3,
flags:<UP,HOST,STATIC>
locks: inits:
sockaddrs: <DST,GATEWAY,NETMASK>
vpn2.net.ic.ac.uk default broadcasthost

got message of size 140 on Sat Aug 27 22:35:22 2011
RTM_ADD: Add Route: len 140, pid: 7342, seq 1, errno 0,
flags:<UP,GATEWAY,HOST,DONE,STATIC>
locks: inits:
sockaddrs: <DST,GATEWAY,NETMASK>
vpn2.net.ic.ac.uk lithium broadcasthost

got message of size 112 on Sat Aug 27 22:35:22 2011
RTM_IFINFO: iface status change: len 112, if# 8, flags:<PTP,MULTICAST>

got message of size 112 on Sat Aug 27 22:35:22 2011
RTM_IFINFO: iface status change: len 112, if# 8,
flags:<PTP,RUNNING,MULTICAST>

got message of size 112 on Sat Aug 27 22:35:22 2011
RTM_IFINFO: iface status change: len 112, if# 8,
flags:<PTP,RUNNING,MULTICAST>

got message of size 80 on Sat Aug 27 22:35:22 2011
RTM_NEWADDR: address being added to iface: len 80, metric 0, flags:
sockaddrs: <NETMASK,IFP,IFA,BRD>
255.255.0.0 ppp0 dyn1246-230.vpn.ic.ac.uk vpn2-vpn.net.ic.ac.uk

got message of size 124 on Sat Aug 27 22:35:23 2011
RTM_ADD: Add Route: len 124, pid: 0, seq 0, errno 0, flags:<UP,HOST>
locks: inits:
sockaddrs: <DST,GATEWAY>
vpn2-vpn.net.ic.ac.uk dyn1246-230.vpn.ic.ac.uk

got message of size 144 on Sat Aug 27 22:35:23 2011
RTM_ADD: Add Route: len 144, pid: 7342, seq 1, errno 0,
flags:<UP,DONE,STATIC>
locks: inits:
sockaddrs: <DST,GATEWAY,NETMASK>
129.31.0.0 ppp0 255.255.0.0

got message of size 112 on Sat Aug 27 22:35:23 2011
RTM_IFINFO: iface status change: len 112, if# 8,
flags:<UP,PTP,RUNNING,MULTICAST>

got message of size 164 on Sat Aug 27 22:35:23 2011
RTM_DELETE: Delete Route: len 164, pid: 14, seq 251, errno 0,
flags:<GATEWAY,DONE,STATIC,PRCLONING,CONDEMNED>
locks: inits:
sockaddrs: <DST,GATEWAY,NETMASK,IFP,IFA>
default 10.3.14.254 default en1:e4.ce.8f.15.7d.c8 10.3.14.1

got message of size 176 on Sat Aug 27 22:35:23 2011
RTM_ADD: Add Route: len 176, pid: 14, seq 252, errno 0,
flags:<UP,GATEWAY,DONE,STATIC>
locks: inits:
sockaddrs: <DST,GATEWAY,NETMASK,IFP,IFA>
default vpn2-vpn.net.ic.ac.uk default ppp0 dyn1246-230.vpn.ic.ac.uk

got message of size 176 on Sat Aug 27 22:35:23 2011
RTM_ADD: Add Route: len 176, pid: 14, seq 253, errno 0, ifscope 5,
flags:<UP,GATEWAY,DONE,STATIC,IFSCOPE>
locks: inits:
sockaddrs: <DST,GATEWAY,NETMASK,IFP,IFA>
default 10.3.14.254 default en1 10.3.14.1

got message of size 180 on Sat Aug 27 22:35:23 2011
RTM_DELETE: Delete Route: len 180, pid: 14, seq 254, errno 3,
flags:<UP,CLONING,STATIC>
locks: inits:
sockaddrs: <DST,GATEWAY,NETMASK,IFP,IFA>
base-address.mcast.net lo0 240.0.0.0 lo0 localhost

<<< I wait, now disconnect >>>

got message of size 136 on Sat Aug 27 22:35:29 2011
RTM_DELETE: Delete Route: len 136, pid: 7342, seq 1, errno 0,
flags:<DONE,STATIC,PRCLONING,CONDEMNED>
locks: inits:
sockaddrs: <DST,GATEWAY,NETMASK>
129.31.0.0 ppp0 (255) ffff ffff

got message of size 124 on Sat Aug 27 22:35:29 2011
RTM_DELETE: Delete Route: len 124, pid: 0, seq 0, errno 0,
flags:<HOST,CONDEMNED>
locks: inits:
sockaddrs: <DST,GATEWAY>
vpn2-vpn.net.ic.ac.uk dyn1246-230.vpn.ic.ac.uk

got message of size 80 on Sat Aug 27 22:35:29 2011
RTM_DELADDR: address being removed from iface: len 80, metric 0,
flags:<UP>
sockaddrs: <NETMASK,IFP,IFA,BRD>
255.255.0.0 ppp0 dyn1246-230.vpn.ic.ac.uk vpn2-vpn.net.ic.ac.uk

got message of size 164 on Sat Aug 27 22:35:29 2011
RTM_DELETE: Delete Route: len 164, pid: 14, seq 255, errno 0,
flags:<GATEWAY,DONE,STATIC,PRCLONING,CONDEMNED>
locks: inits:
sockaddrs: <DST,GATEWAY,NETMASK,IFP,IFA>
default vpn2-vpn.net.ic.ac.uk default ppp0 dyn1246-230.vpn.ic.ac.uk

got message of size 164 on Sat Aug 27 22:35:29 2011
RTM_DELETE: Delete Route: len 164, pid: 14, seq 256, errno 0, ifscope
5, flags:<GATEWAY,DONE,STATIC,PRCLONING,IFSCOPE,CONDEMNED>
locks: inits:
sockaddrs: <DST,GATEWAY,NETMASK,IFP,IFA>
default lithium default en1:e4.ce.8f.15.7d.c8 calcium

got message of size 176 on Sat Aug 27 22:35:29 2011
RTM_ADD: Add Route: len 176, pid: 14, seq 257, errno 0,
flags:<UP,GATEWAY,DONE,STATIC>
locks: inits:
sockaddrs: <DST,GATEWAY,NETMASK,IFP,IFA>
default lithium default en1 calcium

got message of size 180 on Sat Aug 27 22:35:29 2011
RTM_DELETE: Delete Route: len 180, pid: 14, seq 258, errno 3,
flags:<UP,CLONING,STATIC>
locks: inits:
sockaddrs: <DST,GATEWAY,NETMASK,IFP,IFA>
base-address.mcast.net lo0 240.0.0.0 lo0 localhost

got message of size 124 on Sat Aug 27 22:35:30 2011
RTM_DELETE: Delete Route: len 124, pid: 7342, seq 1, errno 0,
flags:<GATEWAY,HOST,DONE,STATIC,CONDEMNED>
locks: inits:
sockaddrs: <DST,GATEWAY>
vpn2.net.ic.ac.uk lithium

It is a bit messy, but allows us to see how Apple do it. Most of it
seems superfluous.

Regards, Freddie.