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. Thanks, Scott
_______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
