[Swan] IP forwarding on a VPN server

Scott A. Wozny sawozny at hotmail.com
Sun Sep 20 20:48:34 UTC 2020

Again, sorry to be a bother, I figured this out after some experimentation.  Consulting the netfilter diagram that Kavinda suggested in combination with turning on iptables TRACE on raw PREROUTING and OUTPUT packets (making sure to exempt traffic from my SSH connection to the management IP; cratered the server the first time not thinking THAT through...  🙂 ) I got a great visual of the journey taken by both the encrypted and decrypted packets and the extensive use of the FORWARD chains made by the unencrypted packets.

So, obviously, net.ipv4.ip_forward=1 is an absolute must for a multi-interface LibreSWAN setup.  🙂  Thanks, Captain Obvious!  🙂


From: Swan <swan-bounces at lists.libreswan.org> on behalf of Scott A. Wozny <sawozny at hotmail.com>
Sent: September 18, 2020 6:10 PM
To: swan at lists.libreswan.org <swan at lists.libreswan.org>
Subject: [Swan] IP forwarding on a VPN server

As I experiment with LibreSWAN, I noticed when I run ‘ipsec verify’ I get a failure for the check, “Two or more interfaces found, checking IP forwarding”. Using the left is local and right is remote convention, I’ve been visualizing LibreSWAN as a process that receives data bound for the right side of the tunnel (by the DIP being an IP within rightsubnets), packages it up into IPSEC packets based upon the rules of the tunnel, and then sends them out the left interface to leftnexthop (if provided) and then in reverse as encrypted packets come into the left interface from the other side.

To me, this does not require IP forwarding since they’re 2 discrete local operations that create completely different packet output, or am I incorrect? OR is this check only for special use cases and, if so, what are those? I didn’t see this device as using the stack’s IP forwarding but if ipsec verify checks and notes the absence of it, does that mean I’m missing something?

My goal is to create a set of VPN servers each with an internal interface (where the plaintext packets enter and leave), external interface (where the encrypted packets enter and leave) and management interface (for system management functions). So if something in that philosophy requires IP forwarding, I’d like to know what that is.

In my mind, the only thing that comes close is when I receive encrypted data from the other side and have to put the decrypted packets on the wire for the local environment, is that going to require some sort of forwarding? My initial assumption is that if I add a local route on the VPN server saying all packets bound for the local resources should be sent to the local router out the “VPN internal” interface for routing to the destination. That’s a form of forwarding but it’s also just basic routing and I haven’t needed to turn forwarding on for any other system to know where to deliver locally generated packets bound for a particular IP.

My current plan is to just continue with my experiments, but if I’m painting myself into a corner, I’d rather know sooner than later.

Any thoughts or suggestions would be appreciated.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20200920/c06fc8eb/attachment-0001.html>

More information about the Swan mailing list