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

[tbk49]

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?

[nero355]

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 ?!

[tbk49]

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?...

[Patrick M. Hausen]

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.

[lmoore]

I 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?

Code Select Expand

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

[Patrick M. Hausen]

I 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.

[lmoore]

I 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.

[nero355]

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?...

I am telling you what I happen to know : That's all :)

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.

Could be... I can't remember anymore... Too long ago...

Also no further experience with GRE or IPSec :)

[tbk49]

I 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?

[tbk49]

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?...

I am telling you what I happen to know : That's all :)

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.

Could be... I can't remember anymore... Too long ago...

Also no further experience with GRE or IPSec :)

Appreciate the feedback nevertheless.

[tbk49]

I 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?

Code Select Expand

@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.

[Patrick M. Hausen]

I 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?

[tbk49]

I 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?

[Patrick M. Hausen]

The most common scenario is either to use a policy based IPsec VPN in tunnel mode without a tunnel interface or use a route based IPsec VPN with a virtual tunnel interface in tunnel mode. I am not aware of any installation that uses GRE in 2026. That's why I asked what you want to achieve with that.

What kind of device is the peer? If it's OPNsense, I'd run WireGuard.

[tbk49]

The most common scenario is either to use a policy based IPsec VPN in tunnel mode without a tunnel interface

'Without a tunnel interface'. Do you mean without something like GRE?

I've set up policy based IPsec, but IPsec is a unicast technology. To do dynamic routing over it where OSPF broadcasts to multicast address this needs to be encapsulated in GRE to pass over the IPsec tunnel. Hence why you run a ptp protocol over IPsec. It was also common at one time to run L2TP over IPsec too. Haven't you ever heard of that either?

Perhaps it is not common in 2026 but this detours from the issue at-hand. The issue being the GRE tunnel doesn't come up unless the firewall is disabled. That doesn't make sense -- I have appropriate firewall rules, so why does the firewall prevent communication? It should be far simpler to get to the explanation for why this is happening than what it will be to spend time removing all the config to set up route based IPsec with VTI.

WG is not possible at the moment.