[Swan] LibreSWAN and iptables

[Scott A. Wozny]

So, I've been futzing around with my configuration and since I can't use ipsec-interface (kernel 3.10) I've been writing FORWARD chain rules for my traffic to pass through.  That seems to be working about how I expected, but I just realized I wrote no rules to permit UDP/500 and UDP/4500 on the interface I've bound ipsec to, yet tunnels come up fine and traffic passes through.  I've checked all 5 netfilter tables for a rule to allow inbound UDP/500 and UDP/4500 but haven't been able to find one.

I doubt it's magic, but I was wondering if you could explain how that traffic is getting in?  I was preparing to write explicit rules to permit it, but if that's not necessary I'd like to be able to check the status of whatever it is that IS allowing it.

Thanks,

Scott

________________________________
From: Swan <swan-bounces at lists.libreswan.org> on behalf of Scott A. Wozny <sawozny at hotmail.com>
Sent: September 15, 2020 6:19 PM
To: Paul Wouters <paul at nohats.ca>
Cc: swan at lists.libreswan.org <swan at lists.libreswan.org>
Subject: Re: [Swan] LibreSWAN and iptables

That's interesting.  I'll have to load my iptables policy up with log lines against a default ACCEPT policy to see the practical effect of this in the writing of my rules.

Thanks,

Scott

________________________________
From: Paul Wouters <paul at nohats.ca>
Sent: September 15, 2020 6:11 PM
To: Scott A. Wozny <sawozny at hotmail.com>
Cc: Wewegama, Kavinda <Kavinda.Wewegama at forcepoint.com>; swan at lists.libreswan.org <swan at lists.libreswan.org>
Subject: Re: [Swan] LibreSWAN and iptables

On Tue, 15 Sep 2020, Scott A. Wozny wrote:

> I had seen that diagram before.  I found the one I mentioned easier to work with, but that was before
> I understood the purpose of the xfrm boxes.  🙂  So I see now that all the IPSec stuff is happening
> not as a normal process, but as a special use case that will, after encoding or decoding send the
> packets back through the PREROUTING / INPUT or OUT / POSTROUTING chanes for further examination
> which, I think, was the piece that was throwing me.  As I dug into xfrm, I found the first 30 minutes
> of this presentation immensely helpful.  https://www.youtube.com/watch?v=7oldcYljp4U

I'm glad that was useful to you :)

Note that with XFRM interface support everything changes again. If you
set ipsec-interface=yes in a conn section, then you get an xfrmi device
called ipsec1. You can then apply all the FORWARD/INPUT/OUTPUT/POST/PRE
rules on that. The encrypted packets (post-encrypt and pre-decrypt) will
appear on the physical interface. The decrypted packets (pre-encrypt and
post-decrypt) will than appear on the ipsec1 virtual interface.

The XFRMi interfaces are a redesign from the VTI interfaces, and in
general work much better although there are still a few use cases
better handled with VTI unfortunately.

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