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: Allan Nathanson <email@hidden>
- Date: Wed, 1 Nov 2006 06:13:57 -0500
How does the tunnel function without an underlying network? If the
tunnel drops when it's own transport is no longer available than you
no longer have a problem.
- Allan
On Nov 1, 2006, at 5:44 AM, Ben Low wrote:
Is there a way to prevent a network service from being selected as
the Primary service?
I'm using OpenVPN (openvpn.org) in tunnel mode, which creates a
POINTTOPOINT link via a tun interface:
e.g.
tun0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 10.4.3.4 --> 10.4.3.1 netmask 0xffffffff
open (pid 20065)
As I want to use the VPN's DNS in addition to the existing DNS, I've
set the openvpn 'up' script to create a Service and populate it with
DNS and IPv4 keys, much as per http://lists.apple.com/archives/Macnetworkprog/2005/Jun/msg00029.html
.
Under normal conditions this results in a routing table that looks
like:
$ netstat -rn -f inet
...
Destination Gateway Flags Refs Use Netif Expire
default 10.254.0.254 UGSc 7 10 en1
10.4.3.1 10.4.3.4 UH 0 0 tun0
10.254.0.99 127.0.0.1 UHS 0 4 lo0
...
which is all good (default points out wireless gateway on en1
(10.254.0.254), vpn server is reachable via tun0)
However, when no other network services are available (e.g. unplug
wired connection, lose wireless signal), the OpenVPN route gets
promoted to the default route:
$ netstat -rn -f inet
...
Destination Gateway Flags Refs Use Netif Expire
default 10.84.43.4 USc 3 0 tun0
10.84.43.1 10.84.43.4 UH 0 0 tun0
Which is not so good - the default route's pointing to the tunnel
interface, so we have a forwarding loop - traffic to/via the openvpn
server gets encapsulated by openvpn and injected into the network,
addressed to the real address of the openvpn server. The (default)
route to that system is in turn now via tun0, i.e. back into openvpn
to be encapsulated again. This quickly chews up 100% CPU with many
network apps begin reporting "out of buffer space" and persists
until the openvpn client exits (e.g. on timeout) and drops the tun
interface, and the tun routes go away.
I've read through the IP Monitor documentation, and I guess what I'm
looking for is something like a NeverPrimary key, nearly opposite in
function to the existing OverridePrimary key. i.e. "never promote
this service to the primary". Any such thing?
Any suggestions for a workaround? I've tried looking to add the
equivalent of a floating static default route (e.g. the equivalent
of "ip route 0.0.0.0 0.0.0.0 null0 200" on an IOS router, or even
just the route to the vpn server rather than the default) - about
the only thing I can come up with is to create a dummy Service, e.g.
d.init
d.add Addresses * 127.0.0.2
d.add InterfaceName lo0
set State:/Network/Service/test/IPv4
But that's pretty nasty, especially as I don't know how to fiddle
the ServiceOrder (?) to make sure it'll get promoted to Primary over
the openvpn service.
Any suggestions?
Rgds,
--
Ben Low
email@hidden
"A mathematician is a device for turning coffee into theorems."
- Paul Erdos
--
Ben Low
email@hidden
"Assassins!" - Arturo Toscanini (1867-1957) to his orchestra
_______________________________________________
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
_______________________________________________
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