[Swan] LibreSWAN and iptables

[Nick Howitt]

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 <swan-bounces at lists.libreswan.org> on behalf of Scott A. 
> Wozny <sawozny at hotmail.com>
> *Sent:* September 19, 2020 8:04 PM
> *To:* Paul Wouters <paul at nohats.ca>
> *Cc:* swan at lists.libreswan.org <swan at lists.libreswan.org>
> *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 <swan-bounces at lists.libreswan.org> on behalf of Scott A. 
> Wozny <sawozny at hotmail.com>
> *Sent:* September 15, 2020 6:19 PM
> *To:* Paul Wouters <paul at nohats.ca>
> *Cc:* swan at lists.libreswan.org <swan at lists.libreswan.org>
> *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 <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
> 
> _______________________________________________
> Swan mailing list
> Swan at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan
>