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
