Why do I need to temporarily disable firewall to bring up peer's GRE interface?

Started by tbk49, July 03, 2026, 05:57:05 PM

Previous topic - Next topic
As the title says, have been troubleshooting incoherent gre behaviour over last day or two, uttering bad words in frustration etc, and have finally found a common thread: if I disable the opnsense firewall (fw | advanced | miscellaneous), the peer's gre tunnel comes up immediately. If I then re-enable the firewall, the tunnel stays up. I can't accept this in a production environment.

I have fw rules on ipsec and WAN to allow GRE protocol.

What is the problem?

https://forum.opnsense.org/index.php?topic=6131.0 --- related?

I have read a long time ago (Think towards 15 to 20 years!) that GRE needs Port 0 forwarded in order to work properly and some Routers could not handle that at the time.

Maybe you are dealing with something similar ?!
Weird guy who likes everything Linux and *BSD on PC/Laptop/Tablet/Mobile and funny little ARM based boards :)

I can't tell whether you are having a joke here or not, but if not, you're telling me opnsense and neither freebsd have solved a 20 year old problem?...

GRE does not have ports. It's its own protocol on top of IP independent of TCP and UDP. Port 0 might be a historical frontend abstraction of some product for not having port numbers at all.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

Quote from: tbk49 on July 03, 2026, 05:57:05 PMI have fw rules on ipsec and WAN to allow GRE protocol.

I don't understand why you would be running GRE over an IPSEC tunnel, is this what you are doing?

Reading through one of the articles, during troubleshooting they mention not setting keep state for the GRE rule.

Have you tried a rule like this for GRE where you have Direction set to Both and set state to no state - advanced option under Stateful firewall?

@625 pass quick on re0 inet proto gre all no state label "c18f1b78-d4dc-46fb-9bb5-61c3ae3d8693"


Quote from: lmoore on July 04, 2026, 10:18:41 AMI don't understand why you would be running GRE over an IPSEC tunnel

At times when VTIs did not yet exist but you wanted a dedicated interface for your IPsec VPN, e.g. to run OSPF on it or similar, a common setup was to establish an IPIP or GRE tunnel and encrypt these packets in transport mode.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

Quote from: Patrick M. Hausen on July 04, 2026, 10:58:59 AM
Quote from: lmoore on July 04, 2026, 10:18:41 AMI don't understand why you would be running GRE over an IPSEC tunnel

At times when VTIs did not yet exist but you wanted a dedicated interface for your IPsec VPN, e.g. to run OSPF on it or similar, a common setup was to establish an IPIP or GRE tunnel and encrypt these packets in transport mode.

Thanks Patrick. That makes sense.

Quote from: tbk49 on July 03, 2026, 09:28:01 PMI can't tell whether you are having a joke here or not, but if not, you're telling me opnsense and neither freebsd have solved a 20 year old problem?...
I am telling you what I happen to know : That's all :)

Quote from: Patrick M. Hausen on July 03, 2026, 09:52:16 PMGRE does not have ports. It's its own protocol on top of IP independent of TCP and UDP. Port 0 might be a historical frontend abstraction of some product for not having port numbers at all.
Could be... I can't remember anymore... Too long ago...

Also no further experience with GRE or IPSec :)
Weird guy who likes everything Linux and *BSD on PC/Laptop/Tablet/Mobile and funny little ARM based boards :)

Quote from: Patrick M. Hausen on July 04, 2026, 10:58:59 AM
Quote from: lmoore on July 04, 2026, 10:18:41 AMI don't understand why you would be running GRE over an IPSEC tunnel

At times when VTIs did not yet exist but you wanted a dedicated interface for your IPsec VPN, e.g. to run OSPF on it or similar, a common setup was to establish an IPIP or GRE tunnel and encrypt these packets in transport mode.

I am using tunnel mode, not transport. That a problem?

Quote from: nero355 on July 04, 2026, 04:58:47 PM
Quote from: tbk49 on July 03, 2026, 09:28:01 PMI can't tell whether you are having a joke here or not, but if not, you're telling me opnsense and neither freebsd have solved a 20 year old problem?...
I am telling you what I happen to know : That's all :)

Quote from: Patrick M. Hausen on July 03, 2026, 09:52:16 PMGRE does not have ports. It's its own protocol on top of IP independent of TCP and UDP. Port 0 might be a historical frontend abstraction of some product for not having port numbers at all.
Could be... I can't remember anymore... Too long ago...

Also no further experience with GRE or IPSec :)

Appreciate the feedback nevertheless.

Quote from: lmoore on July 04, 2026, 10:18:41 AM
Quote from: tbk49 on July 03, 2026, 05:57:05 PMI have fw rules on ipsec and WAN to allow GRE protocol.

I don't understand why you would be running GRE over an IPSEC tunnel, is this what you are doing?

Reading through one of the articles, during troubleshooting they mention not setting keep state for the GRE rule.

Have you tried a rule like this for GRE where you have Direction set to Both and set state to no state - advanced option under Stateful firewall?

@625 pass quick on re0 inet proto gre all no state label "c18f1b78-d4dc-46fb-9bb5-61c3ae3d8693"



Since I'm running GRE over IPSec, do I need a GRE rule on WAN, or only IPsec interface, and if only on the IPsec interface, does your suggestion still apply? My understanding is you have a GRE rule on the WAN if you're pointing GRE directly at your WAN IP. I'm not, as I'm using GRE through IPsec. IPsec certainly contacts the WAN IP on UDP 500/4500 though.

Quote from: tbk49 on July 05, 2026, 08:45:46 PMI am using tunnel mode, not transport. That a problem?

That entirely depends on what you want to achieve and how the other side is configured.

In tunnel mode as used in most scenarios you would not run an additional GRE tunnel inside the IPsec tunnel. Why are you doing that?
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

Quote from: Patrick M. Hausen on July 05, 2026, 09:17:23 PM
Quote from: tbk49 on July 05, 2026, 08:45:46 PMI am using tunnel mode, not transport. That a problem?

That entirely depends on what you want to achieve and how the other side is configured.

In tunnel mode as used in most scenarios you would not run an additional GRE tunnel inside the IPsec tunnel. Why are you doing that?

Maybe because I'm inexperienced and haven't spent months reading the RFCs?

I'm running a site-to-site connection. I'm not sure what you mean by "inside", but my understanding is "GRE/IPSec" = "GRE over IPSec" meaning your local tunnel address is the IPSec loopback IP and the remote tunnel address is the IPSec loopback of the peer. Then you give the GRE interface its own private IP. Then you do dynamic routing via GRE. So for example:-

Device A:

loopback (for IPSec) - 10.22.22.1/30
GRE interface local address - 10.22.22.1/30
GRE interface remote address - 10.22.22.2/30
GRE interface IP - 172.25.1.1/30

Device B:

loopback (for IPSec) - 10.22.22.2/30
GRE interface local address - 10.22.22.2/30
GRE interface remote address - 10.22.22.1/30
GRE interface IP - 172.25.1.2/30

After the IPSec connection passes Phase 2 the GRE interface comes up (should...) and communication is via 172.25.1.0/30 network. Is this what you mean by running GRE 'inside' IPsec? Because if so, that's what I'm doing. What is the most common scenario you refer to?