Fairly standard iptables rules are:
# Generic IPsec rules - normally you don't need the last two
$IPTABLES -I INPUT -m policy --dir in --pol ipsec -j ACCEPT
$IPTABLES -I FORWARD -m policy --dir in --pol ipsec -j ACCEPT
$IPTABLES -I POSTROUTING -t nat -m policy --dir out --pol ipsec -j ACCEPT
#$IPTABLES -I OUTPUT -m policy --dir out --pol ipsec -j ACCEPT # only
needed if you have restrictive outgoing rules
#$IPTABLES -I FORWARD -m policy --dir out --pol ipsec -j ACCEPT # only
needed if you have restrictive outgoing rules
It also assumes you have ACCEPT rules for all RELATED and ESTABLISHED
traffic.
In your POSTROUTING chain you, if you have generic MASQUERADE rules, you
can avoid a separate POSTROUTING rule if you exclude ipsec traffic from
them. I think you add "! -m policy --dir out --pol ipsec" but I cant
remember for sure where the "!" goes.
Nick
On 15/09/2020 04:12, Wewegama, Kavinda wrote:
Hi Scott,
Have you seen this diagram before:
https://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg
<https://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg>
It might answer some of your questions.
Thanks.
-Kavinda
*From:* Swan <[email protected]> *On Behalf Of *Scott A.
Wozny
*Sent:* Monday, September 14, 2020 5:24 PM
*To:* [email protected]
*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
<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
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
