<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Hi Nick,</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);">
Interesting! I didn't know these match rules were available. I still need to figure out exactly where to apply IPSec policy rules and where exactly to apply rules on the plaintext traffic as I'm using a zone based firewall, but that's just going to involve
legwork (and probably adding a bunch of logging rules in iptables).</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 very much,</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="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="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 Nick Howitt <nick@howitts.co.uk><br>
<b>Sent:</b> September 15, 2020 4:26 AM<br>
<b>To:</b> swan@lists.libreswan.org <swan@lists.libreswan.org><br>
<b>Subject:</b> Re: [Swan] LibreSWAN and iptables</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt">
<div class="PlainText">Fairly standard iptables rules are:<br>
# Generic IPsec rules - normally you don't need the last two<br>
$IPTABLES -I INPUT -m policy --dir in --pol ipsec -j ACCEPT<br>
$IPTABLES -I FORWARD -m policy --dir in --pol ipsec -j ACCEPT<br>
$IPTABLES -I POSTROUTING -t nat -m policy --dir out --pol ipsec -j ACCEPT<br>
#$IPTABLES -I OUTPUT -m policy --dir out --pol ipsec -j ACCEPT # only <br>
needed if you have restrictive outgoing rules<br>
#$IPTABLES -I FORWARD -m policy --dir out --pol ipsec -j ACCEPT # only <br>
needed if you have restrictive outgoing rules<br>
<br>
It also assumes you have ACCEPT rules for all RELATED and ESTABLISHED <br>
traffic.<br>
<br>
In your POSTROUTING chain you, if you have generic MASQUERADE rules, you <br>
can avoid a separate POSTROUTING rule if you exclude ipsec traffic from <br>
them. I think you add "! -m policy --dir out --pol ipsec" but I cant <br>
remember for sure where the "!" goes.<br>
<br>
Nick<br>
<br>
On 15/09/2020 04:12, Wewegama, Kavinda wrote:<br>
> Hi Scott,<br>
> <br>
> Have you seen this diagram before: <br>
> <a href="https://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg">
https://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg</a>
<br>
> <<a href="https://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg">https://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg</a>>
<br>
> <br>
> <br>
> It might answer some of your questions.<br>
> <br>
> Thanks.<br>
> <br>
> -Kavinda<br>
> <br>
> *From:* Swan <swan-bounces@lists.libreswan.org> *On Behalf Of *Scott A. <br>
> Wozny<br>
> *Sent:* Monday, September 14, 2020 5:24 PM<br>
> *To:* swan@lists.libreswan.org<br>
> *Subject:* EXTERNAL: [Swan] LibreSWAN and iptables<br>
> <br>
> My tenuous grip on iptables (and reality) is based upon this chart.<br>
> <br>
> <a href="https://stuffphilwrites.com/wp-content/uploads/2014/09/FW-IDS-iptables-Flowchart-v2019-04-30-1.png">
https://stuffphilwrites.com/wp-content/uploads/2014/09/FW-IDS-iptables-Flowchart-v2019-04-30-1.png</a>
<br>
> <<a href="https://stuffphilwrites.com/wp-content/uploads/2014/09/FW-IDS-iptables-Flowchart-v2019-04-30-1.png">https://stuffphilwrites.com/wp-content/uploads/2014/09/FW-IDS-iptables-Flowchart-v2019-04-30-1.png</a>><br>
> <br>
> With most of the work I’m doing, the processing flow of packets and <br>
> applications is easy to understand. It’s an incoming or an outgoing <br>
> packet and if it’s not both it’s either locally generated or locally <br>
> processed by a process. This works for all my servers and firewalls <br>
> except for LibreSWAN because it seems (at least to me) to simultaneously <br>
> exist as an application and a router.<br>
> <br>
> I’m trying to understand how LibreSWAN fits with the diagram referenced <br>
> above and my understanding of iptables. For example, when an unencrypted <br>
> packet comes in on the LAN side, is it processed through the PREROUTING <br>
> and INPUT chains to the ipsec process or is it processed through the <br>
> PREROUTING and FORWARD chains and, if so, where does the actual <br>
> encryption and inclusion in the IPSec payload occur? Conversely when <br>
> IPSec tunnel traffic is created by the ipsec process, does that traffic <br>
> start life as a Locally Generated Packet subject to OUTPUT and <br>
> POSTROUTING chains, or is it considered forwarded traffic and sent <br>
> through the FORWARD and POSTROUTING chains, again, raising the question <br>
> of where in the diagram the encryption occurs?<br>
> <br>
> The reason I’m trying to get a better hold of this is two-fold. First, I <br>
> need to know how routing handles these packets at each stage (because <br>
> the IPs change), mostly so I can figure out how to send out decrypted <br>
> data bound for the LAN out the LAN interface while still keeping VPN <br>
> server management traffic to the management interface knowing that there <br>
> will be overlap in the destinations. Second, I need to know how to write <br>
> local firewall rules and what chains to apply filtering and NAT’ing <br>
> rules to at various stages of transmission.<br>
> <br>
> Is there a resource describing this dance or does a simple rule of thumb <br>
> exist that I’m missing? Two options that come to mind are:<br>
> <br>
> 1) LibreSWAN operates fundamentally as an application. The FORWARD chain <br>
> never gets involved so all packets are processed incoming through <br>
> PREROUTING and INPUT chains to local processing with the encryption / <br>
> decryption operations under control of the ipsec process followed by <br>
> “locally generated” ipsec packets being processed through OUTPUT and <br>
> POSTROUTING until the outgoing packet leaves the system?<br>
> <br>
> 2) LibreSWAN operates fundamentally as a router rather than a process <br>
> and everything passes through the PREROUTING, FORWARD, POSTROUTING <br>
> chains and nothing is considered INPUT or OUTPUT (or locally generated / <br>
> locally processed)? But in this case where is the encryption / packaging <br>
> occurring relative to iptables?<br>
> <br>
> Or maybe things aren’t that simple… Any suggestions for further research <br>
> would be appreciated.<br>
> <br>
> Thanks,<br>
> <br>
> Scott<br>
> <br>
> <br>
> _______________________________________________<br>
> Swan mailing list<br>
> Swan@lists.libreswan.org<br>
> <a href="https://lists.libreswan.org/mailman/listinfo/swan">https://lists.libreswan.org/mailman/listinfo/swan</a><br>
> <br>
<br>
_______________________________________________<br>
Swan mailing list<br>
Swan@lists.libreswan.org<br>
<a href="https://lists.libreswan.org/mailman/listinfo/swan">https://lists.libreswan.org/mailman/listinfo/swan</a><br>
</div>
</span></font></div>
</div>
</body>
</html>