Figured it out. Sorry to have been a bother. Considering how UDP is connectionless and that SPORT and DPORT on both the ISAKMP and the IPSEC-NAT-T packets are the same, obviously any stateful firewall without an ALG for the protocol would see a packet in each direction and that would count as closely to an established connection as conntrack would ever be able to figure out, which is why this functions without an explicit firewall rule.
Obviously the very first packet passed would never get though, but ISAKMP and IPSec being peer protocols would have it baked in that somebody would always be up first and waiting for the other so those first dropped packets would be inherently accommodated for in any grown-up implementation, right? 🙂 ________________________________ From: Swan <[email protected]> on behalf of Scott A. Wozny <[email protected]> Sent: September 19, 2020 8:04 PM To: Paul Wouters <[email protected]> Cc: [email protected] <[email protected]> Subject: Re: [Swan] LibreSWAN and iptables 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 <[email protected]> on behalf of Scott A. Wozny <[email protected]> Sent: September 15, 2020 6:19 PM To: Paul Wouters <[email protected]> Cc: [email protected] <[email protected]> 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 <[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
