[Swan] LibreSWAN and iptables

[Scott A. Wozny]

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/20200915/569bf40c/attachment-0001.html>