[Swan] LibreSWAN and iptables

Tue Sep 15 21:58:48 UTC 2020

Hi Kavinda,

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

Thanks very much for your reply.

Scott

________________________________
From: Wewegama, Kavinda <Kavinda.Wewegama at forcepoint.com>
Sent: September 14, 2020 11:12 PM
To: Scott A. Wozny <sawozny at hotmail.com>; swan at lists.libreswan.org <swan at lists.libreswan.org>
Subject: RE: LibreSWAN and iptables

Hi Scott,

Have you seen this diagram before: https://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg

It might answer some of your questions.

Thanks.

-Kavinda

From: Swan <swan-bounces at lists.libreswan.org> On Behalf Of Scott A. Wozny
Sent: Monday, September 14, 2020 5:24 PM
To: swan at lists.libreswan.org
Subject: EXTERNAL: [Swan] LibreSWAN and iptables

My tenuous grip on iptables (and reality) is based upon this chart.

https://stuffphilwrites.com/wp-content/uploads/2014/09/FW-IDS-iptables-Flowchart-v2019-04-30-1.png

With most of the work I’m doing, the processing flow of packets and applications is easy to understand. It’s an incoming or an outgoing packet and if it’s not both it’s either locally generated or locally processed by a process. This works for all my servers and firewalls except for LibreSWAN because it seems (at least to me) to simultaneously exist as an application and a router.

I’m trying to understand how LibreSWAN fits with the diagram referenced above and my understanding of iptables. For example, when an unencrypted packet comes in on the LAN side, is it processed through the PREROUTING and INPUT chains to the ipsec process or is it processed through the PREROUTING and FORWARD chains and, if so, where does the actual encryption and inclusion in the IPSec payload occur? Conversely when IPSec tunnel traffic is created by the ipsec process, does that traffic start life as a Locally Generated Packet subject to OUTPUT and POSTROUTING chains, or is it considered forwarded traffic and sent through the FORWARD and POSTROUTING chains, again, raising the question of where in the diagram the encryption occurs?

The reason I’m trying to get a better hold of this is two-fold. First, I need to know how routing handles these packets at each stage (because the IPs change), mostly so I can figure out how to send out decrypted data bound for the LAN out the LAN interface while still keeping VPN server management traffic to the management interface knowing that there will be overlap in the destinations. Second, I need to know how to write local firewall rules and what chains to apply filtering and NAT’ing rules to at various stages of transmission.

Is there a resource describing this dance or does a simple rule of thumb exist that I’m missing? Two options that come to mind are:

1) LibreSWAN operates fundamentally as an application. The FORWARD chain never gets involved so all packets are processed incoming through PREROUTING and INPUT chains to local processing with the encryption / decryption operations under control of the ipsec process followed by “locally generated” ipsec packets being processed through OUTPUT and POSTROUTING until the outgoing packet leaves the system?

2) LibreSWAN operates fundamentally as a router rather than a process and everything passes through the PREROUTING, FORWARD, POSTROUTING chains and nothing is considered INPUT or OUTPUT (or locally generated / locally processed)? But in this case where is the encryption / packaging occurring relative to iptables?

Or maybe things aren’t that simple… Any suggestions for further research would be appreciated.

Thanks,

Scott

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20200915/e0326275/attachment-0001.html>