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
