Hi Nick, 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).
Thanks very much, Scott ________________________________ From: Swan <[email protected]> on behalf of Nick Howitt <[email protected]> Sent: September 15, 2020 4:26 AM To: [email protected] <[email protected]> Subject: Re: [Swan] LibreSWAN and iptables 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
_______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
