[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1219
  • 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.

Cheers,
-Jon

[ **** Edited by The--Captain - removed frustrated rants **** ]
0
The--Captain
Asked:
The--Captain
  • 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?
0
 
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.

Thanks,
-Jon
0
 
The--CaptainAuthor Commented:
This would have led me to the correct solution, had I already not discovered it first.
0

Featured Post

A Cyber Security RX to Protect Your Organization

Join us on December 13th for a webinar to learn how medical providers can defend against malware with a cyber security "Rx" that supports a healthy technology adoption plan for every healthcare organization.

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