Indeed, I have already fixed it and that is exactly the solution I used.
To get the packets to be passed along to the linux routing engine (to exempt them from being handed off to openswan) such that they use my alternate circuit, I used (except that I used my real IPs, and a /32 mask to exempt just two hosts):
ip xfrm policy add dir fwd src a.b.c.d/e dst f.g.h.i/j
ip xfrm policy add dir fwd dst a.b.c.d/e src f.g.h.i/j
ip xfrm policy add dir in src a.b.c.d/e dst f.g.h.i/j
ip xfrm policy add dir out dst a.b.c.d/e src f.g.h.i/j
I don't know if all of those are necessary, but it's working for me currently.
Thanks,
-Jon
Main Topics
Browse All Topics
by: MonitorSupportPosted on 2009-04-08 at 03:41:37ID: 24095531
Alternatively and probably a better solution would be to add the backup route to the Security Policy table instead of changing the matching orders around.
I.e. 'ip xfrm policy list' shows you the current security policies as created by openswan when VPNs establish.
How could I use 'ip xfrm policy add ...' to insert the necessary Security Policies to act as backup VPN routes when the openswan tunnel policies are not in place?