That's the interesting part. I control the firewall on both sides and neither one explicitly allows new connections inbound over UDP/500 or UDP/4500 which was the initial source of the mystery. HOWEVER, as part of a standard firewalld iptables ruleset, anything conntrack sees as an ESTABLISHED connection is permitted inbound. In the case of TCP traffic, the 3 way handshake needs to pass to get traffic into the ESTABLISHED club, but for UDP all it needs to see is symmetrical traffic and that's the best it can do in the absence of an ALG.
So when the firewall sees AA.AA.AA.AA (UDP/500) -> BB.BB.BB.BB (UDP/500) AND BB.BB.BB.BB (UDP/500) -> AA.AA.AA.AA (UDP/500) (looks like a reply, but actually isn't) even though they're separate session setup packets they're also indistinguishable from a "properly established" ongoing UDP connection, so conntrack sees this and allows the traffic under the category ESTABLISHED. It's technically a security hole in the firewall, but it also can only happen in very particular situations like this one AND you need to control both sides of the conversation, so I'm not losing a lot of sleep over it. I think I'll eventually need to explicitly allow the traffic inbound when I turn on remote access / road warrior connections because THEN I won't have both sides trying each other and fooling the firewall into thinking it's a real conversation before it actually is. But it was interesting to see this. Thanks, Scott ________________________________ From: Swan <[email protected]> on behalf of Nick Howitt <[email protected]> Sent: September 20, 2020 4:08 AM To: [email protected] <[email protected]> Subject: Re: [Swan] LibreSWAN and iptables It depends on your configs. If both side have auto=start then both sides will try to initiate the connection. The far side will fail because your firewall is closed, but if their firewall is open, you can initiate the connection. Nick On 20/09/2020 02:59, Scott A. Wozny wrote: > 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 > _______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
_______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
