<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div>
<div id="appendonsend" style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
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. 
<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
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?  <span id="🙂">🙂</span></div>
<div style="font-family:Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><b>From:</b> Swan <swan-bounces@lists.libreswan.org> on behalf of Scott A. Wozny <sawozny@hotmail.com><br>
<b>Sent:</b> September 19, 2020 8:04 PM<br>
<b>To:</b> Paul Wouters <paul@nohats.ca><br>
<b>Cc:</b> swan@lists.libreswan.org <swan@lists.libreswan.org><br>
<b>Subject:</b> Re: [Swan] LibreSWAN and iptables</font>
<div> </div>
</div>
<div dir="ltr">
<div style="font-family:Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
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. 
<br>
</div>
<div style="font-family:Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
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.</div>
<div style="font-family:Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Thanks,</div>
<div style="font-family:Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
Scott<br>
</div>
<div>
<div id="x_appendonsend"></div>
<div style="font-family:Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><b>From:</b> Swan <swan-bounces@lists.libreswan.org> on behalf of Scott A. Wozny <sawozny@hotmail.com><br>
<b>Sent:</b> September 15, 2020 6:19 PM<br>
<b>To:</b> Paul Wouters <paul@nohats.ca><br>
<b>Cc:</b> swan@lists.libreswan.org <swan@lists.libreswan.org><br>
<b>Subject:</b> Re: [Swan] LibreSWAN and iptables</font>
<div> </div>
</div>
<div dir="ltr">
<div style="font-family:Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
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.</div>
<div style="font-family:Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Thanks,</div>
<div style="font-family:Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Scott<br>
</div>
<div>
<div id="x_x_appendonsend"></div>
<div style="font-family:Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_x_divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><b>From:</b> Paul Wouters <paul@nohats.ca><br>
<b>Sent:</b> September 15, 2020 6:11 PM<br>
<b>To:</b> Scott A. Wozny <sawozny@hotmail.com><br>
<b>Cc:</b> Wewegama, Kavinda <Kavinda.Wewegama@forcepoint.com>; swan@lists.libreswan.org <swan@lists.libreswan.org><br>
<b>Subject:</b> Re: [Swan] LibreSWAN and iptables</font>
<div> </div>
</div>
<div class="x_x_BodyFragment"><font size="2"><span style="font-size:11pt">
<div class="x_x_PlainText">On Tue, 15 Sep 2020, Scott A. Wozny wrote:<br>
<br>
> I had seen that diagram before.  I found the one I mentioned easier to work with, but that was before<br>
> I understood the purpose of the xfrm boxes.  ðŸ™‚  So I see now that all the IPSec stuff is happening<br>
> not as a normal process, but as a special use case that will, after encoding or decoding send the<br>
> packets back through the PREROUTING / INPUT or OUT / POSTROUTING chanes for further examination<br>
> which, I think, was the piece that was throwing me.  As I dug into xfrm, I found the first 30 minutes<br>
> of this presentation immensely helpful.  <a href="https://www.youtube.com/watch?v=7oldcYljp4U">
https://www.youtube.com/watch?v=7oldcYljp4U</a> <br>
<br>
I'm glad that was useful to you :)<br>
<br>
Note that with XFRM interface support everything changes again. If you<br>
set ipsec-interface=yes in a conn section, then you get an xfrmi device<br>
called ipsec1. You can then apply all the FORWARD/INPUT/OUTPUT/POST/PRE<br>
rules on that. The encrypted packets (post-encrypt and pre-decrypt) will<br>
appear on the physical interface. The decrypted packets (pre-encrypt and<br>
post-decrypt) will than appear on the ipsec1 virtual interface.<br>
<br>
The XFRMi interfaces are a redesign from the VTI interfaces, and in<br>
general work much better although there are still a few use cases<br>
better handled with VTI unfortunately.<br>
<br>
Paul<br>
</div>
</span></font></div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>