• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1233
  • Last Modified:

openswan stealing more specifically routed packets?

I have an ipsec connection via openswan between two RFC1918 /24 subnets using linux (one old redhat, one new debian), which works fine.  I am now trying to route packets between two discreet hosts in those /24s over a different connection (adding host routes pointing at the router(s) which handle the new connection - the two hosts are part of a VoIP system that needs to use the new connection to avoid latency and other issues associated with the ipsec VPN).

Here's the problem - on the old redhat box (freeswan 1.x), the addition of the host route cause the desired result - the packets from one discreet host to the other travel out the interface which is connected to the router handling that end of the new connection, rather than the ipsec interface.  Perfect.  However, on the debian box (freeswan 2.x), the packets continue to be transmitted via the ipsec connection, even though I have more specific [host] route via the new connection.  WTF, mate?

This has all been verified with local sniffers (tcpdump).

Any ideas how to get around this?  

I suspect that this might be able to be worked around using "ip xfrm", experimental netfilter extensions (particularly the ROUTE destination), or policy routing using iproute2 tools, but this just seems silly, and overly complex.


[ **** Edited by The--Captain - removed frustrated rants **** ]
  • 2
1 Solution
Monitor SupportSupport TeamCommented:
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?
The--CaptainAuthor Commented:
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.

The--CaptainAuthor Commented:
This would have led me to the correct solution, had I already not discovered it first.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

We Need Your Input!

WatchGuard is currently running a beta program for our new macOS Host Sensor for our Threat Detection and Response service. We're looking for more macOS users to help provide insight and feedback to help us make the product even better. Please sign up for our beta program today!

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now