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 <[email protected]> Sent: September 15, 2020 6:11 PM To: Scott A. Wozny <[email protected]> Cc: Wewegama, Kavinda <[email protected]>; [email protected] <[email protected]> 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
_______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
