Re: [LARTC] Routing with two providers

["Jason A. Pattie" <pattieja@pcxperience.com>]

Julian Anastasov wrote:

>>The only problem that I have had with Julian's patches is interoperation
>>with FreeS/WAN.  I am still not able to make that work, although I
>>haven't worked on it in awhile.  The last I remember is that with the
>>patches applied, the moment FreeS/WAN starts, all network traffic goes
>>out the ipsec0 interface instead of continuing to be routed via eth0 (or
>>whichever interface).  This happens without a tunnel brought up.  And
>>
>
>	Hm. IIRC, the default updown script in FreeSWAN creates
>routes with the "route" utility.
>
That is correct.

> That means they are
>"from all to remote_net via XXX dev ipsecX". FreeSWAN is ready
>for this, it just forwards the gw->gw traffic via the configured
>nexthop without encryption, so it looks like it is not related to
>the route patches. Is that correct?
>
I don't know.  If the patch is not in the kernel, everything works fine. 
 The moment I boot with the patched kernel, normal networking stops 
working the once ipsec is started.  The defaultroute routes are added 
apparently before any tunnels are brought up.  An ipsecN interface is 
bound to whichever interface (eth0, eth1, ..., ethN) you have specified. 
 Routes are then added that mirror the routes to these devices for the 
network of that device.  Without the patch, this problem can be 
duplicated if you first bring down normal networking (ifdown eth0) but 
leave FreeS/WAN running.  Then restart normal networking (ifup eth0) and 
the routes will be reversed in the routing table apparently giving 
precedence to ipsecN routes.  This causes all normal traffic to be 
attempted to be sent through the ipsec interface instead of the normal 
ethN interface that the ipsecN interface is bound to.  Apparently 
something very similar happens with the patches in place, because if the 
ipsec routes are removed manually and reinserted into the running kernel 
AFTER the routes for the normal network interface, things start working 
again.  The only way I could get that to work was by assigning a metric 
(somehow) to the normal networking route (or maybe it was the ipsec 
networking route).  Then the normal networking route took precedence 
over the ipsec networking route.

>>for some reason, I was not able to assign a metric to the route using
>>either the 'route' command or 'ip route'.
>>
>If you try to add different metric to the different
>alternative routes this is not possible by design. All alternative
>routes have same metric value. This is the difference between
>"ip route add" and "ip route append".
>
Hmm.  Didn't realize there was a difference.

-- 
Jason A. Pattie
pattieja@pcxperience.com


_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/