Hi.
I was trying to debug a Strongswan issue involving GRE-over-IPSec (ESP transport mode) and my decapsulated GRE packets were causing ICMP Unreachables (administrative prohibited).
Looking at the ICMP, it was for the GRE packet itself.
So I got around the problem by doing:
# firewall-cmd --permanent --zone=public --add-protocol=gre
But this means that my firewall will now accept cleartext GRE, which (in the case of misconfiguration and the packets not being protected via IPSec encryption) is something that I REALLY don’t want to happen.
I’ve not dived into the bowels of firewalld (in fact, I’m more versed in iptables than nftables), but I’ve worked on firewalls before (Cisco IOS, Arno’s Internet Firewall, OpenWrt’s firewall3, etc) over the last 20+ years.
It seems to me that packets that are decapsulated and then re-injected into the FORWARD or INPUT chains (in iptables) usually are either just ACCEPT’d or else are passed through a separate but similar chain.
Would it make sense to do something similar in firewalld?
Otherwise, it looks like I need to dig into making some fairly hairy “rich” rules. Has anyone done that either?
Thanks,
-Philip
On Fri, Aug 14, 2020 at 01:41:14PM -0600, Philip Prindeville wrote:
Hi.
I was trying to debug a Strongswan issue involving GRE-over-IPSec (ESP transport mode) and my decapsulated GRE packets were causing ICMP Unreachables (administrative prohibited).
Looking at the ICMP, it was for the GRE packet itself.
So I got around the problem by doing:
# firewall-cmd --permanent --zone=public --add-protocol=gre
But this means that my firewall will now accept cleartext GRE, which (in the case of misconfiguration and the packets not being protected via IPSec encryption) is something that I REALLY don’t want to happen.
I’ve not dived into the bowels of firewalld (in fact, I’m more versed in iptables than nftables), but I’ve worked on firewalls before (Cisco IOS, Arno’s Internet Firewall, OpenWrt’s firewall3, etc) over the last 20+ years.
It seems to me that packets that are decapsulated and then re-injected into the FORWARD or INPUT chains (in iptables) usually are either just ACCEPT’d or else are passed through a separate but similar chain.
Would it make sense to do something similar in firewalld?
firewalld can only do what is supported by iptables/nftables.
Both iptables and nftables support matching ipsec fields. I think this would be enough for you to accept the GRE-oven-ipsec while not accepting plaintext GRE. Unfortunately, this is not expose in firewalld - feel free to open an RFE.
You might be able to do it with a direct rule though.
firewalld-users@lists.fedorahosted.org