Re: Preventing a Network Service from becoming Primary
Re: Preventing a Network Service from becoming Primary
- Subject: Re: Preventing a Network Service from becoming Primary
- From: Ben Low <email@hidden>
- Date: Fri, 3 Nov 2006 00:23:41 +1100
On 02/11/2006, at 3:31 AM, Allan Nathanson wrote:
When the underlying network and tunnel are both up, what network
routes are active?
Physical ethernet up, connected to 172.29.9/26.VPN server is "out in
the internet", reachable via default gateway 172.29.9.1:
$ netstat -rn -f inet
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif
Expire
default 172.29.9.1 UGSc 10 14 en0
10.84.42/24 10.84.43.1 UGSc 1 4 tun0
10.84.43.1 10.84.43.4 UH 2 0 tun0
127 127.0.0.1 UCS 0 0 lo0
127.0.0.1 127.0.0.1 UH 15 1082330 lo0
172.29.9/26 link#4 UCS 3 0 en0
172.29.9.1 0:0:c:7:ac:0 UHLW 11 0
en0 477
172.29.9.22 0:50:4:b6:ea:b6 UHLW 0 0
en0 659
172.29.9.26 127.0.0.1 UHS 0 0 lo0
172.29.9.63 ff:ff:ff:ff:ff:ff UHLWb 0 6 en0
169.254 link#4 UCS 0 0 en0
So you can see I have a host route for the OpenVPN tunnel (line 3)
and another route to the inside network (line 2), both via tun0.
Take ethernet down:
$ sudo ifconfig en0 down
$ netstat -rn -f inet
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif
Expire
default 10.84.43.4 USc 4 2 tun0
10.84.42/24 10.84.43.1 UGSc 1 20 tun0
10.84.43.1 10.84.43.4 UH 2 0 tun0
127 127.0.0.1 UCS 0 0 lo0
127.0.0.1 127.0.0.1 UH 18 1094649 lo0
- CPU hits 100% with openvpn reporting "write UDPv4: No buffer space
available (code=55)" (as do other apps that try to use the network ,
e.g. mDNSResponder: mDNSPlatformSendUDP sendto failed to send packet
on InterfaceID 00000000 unicast/4 to 10.84.42.254:53 skt 7 error -1
errno 55 (No buffer space available) 256814
2396)
- this is expected from the routing table: the machine directs all
traffic other than 127/8 to the tunnel and OpenVPN. OpenVPN of then
encapsulates the data read from the tun0 interface and hands the new
UDP packet over to the o/s for delivery to the openvpn server - which
then proceeds to forward (back) to tun0 per the default route.
- i.e. I really want to stop that 'default 10.84.43.4 ... tun0'
route (line 1) from being created.
Ok, so a little while later openvpn times out (recall: UDP transport)
and closes the tunnel, taking down the tun0 interface:
$ netstat -rn -f inet
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif
Expire
127 127.0.0.1 UCS 0 0 lo0
127.0.0.1 127.0.0.1 UH 18 1095511 lo0
224.0.0/4 127.0.0.1 UCS 2 0 lo0
224.0.0.251 127.0.0.1 UHW 1 2 lo0
239.255.255.253 127.0.0.1 UHW 1 30 lo0
- all we have left is lo0, and no default
Now, when the underlying network is removed, what network routes
would make sense?
I would expect to see this, for the period between dropping real
connectivity but before openvpn closes up shop:
Destination Gateway Flags Refs Use Netif
Expire
10.84.42/24 10.84.43.1 UGSc 1 20 tun0
10.84.43.1 10.84.43.4 UH 2 0 tun0
127 127.0.0.1 UCS 0 0 lo0
127.0.0.1 127.0.0.1 UH 18 1094649 lo0
- i.e. as per the middle case above, but without the default;
openvpn's encapsulated traffic gets dropped / no route, just as with
any other non-127/8 traffic
Are you suggesting that there simply be no default route?
Yes. Just as when you're not connected to anything other than loopback.
... and I doubt that you'll get very far with the
kSCPropNetIPv4Router property since the entire configuration is
driven to make things work for the active service with the highest
priority.
Fair enough... I would agree that in the general case it makes a
great deal of sense to just keep promoting services until you get a
default route, as a user it's great to not have to worry about
switching wireless off and on when connecting here and there (ditto
ppp, etc). It all "just works". But when it comes to VPNs, it doesn't
make sense - these can only ever be the default when there is an
explicit route to the server already in the route table - a
conditional default at best, if you will.
Doesn't this same problem crop up with non-split-tunnelled IPSec
(i.e. an IPSec tunnel where the default points over the tunnel)?
(PPTP avoids the problem as it would get a TCP reset on trying to
send the next packet after the real network goes down - still,
there's a race condition there...).
The only way I can see to mitigate this problem is to set up a kicker
script to signal openvpn to timeout immediately on network changes -
kind of turning the openvpn case into the same as PPTP: shrinking but
not eliminating the problem. Not as nice as could be, but should
work... (is there a better way in user-land of being alerted to a
network state change than hacking /System/Library/SystemConfiguration/
Kicker.bundle/Contents/Resources/{Kicker.xml,enable-network}?)
Thanks,
Ben
--
Ben Low
email@hidden
"I'll moider da bum." - Heavyweight boxer Tony Galento, when asked
what he thought of William Shakespeare
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden