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
