All non-ping traffic over GRE/IPsec blocked by "Default deny rule IPv4"
-
Hi folks - just unpacked my brand new cadre of SG-2440s from the pfSense store, and trying to sort this VPN issue:
I have a GRE tunnel carried over an IPsec transport, with static routes set up for testing (going to use OSPF once this issue is resolved). I can ping between LAN subnets with no issue, but all traffic other than ping is blocked on the receiving side by "@6(10000000104) block drop out log inet all label "Default deny rule IPv4"".
Note: When I first brought the tunnel up, I had to manually remove an outbound NAT rule for the GRE gateway that pfSense automagically created to get traffic to pass at all. I don't want NAT on GRE traffic, so this action made sense, but if I somehow screwed myself by doing this please let me know :)
-
I've verified that it's not packet size by pinging with 1500 byte packets, which worked fine.
-
One more bit of info - there is an arrow next to the GRE interface name in firewall logs, meaning it was blocked outbound. The docs suggest this is due to "out of state" traffic, but I'm not sure where to go from here… I did change state to "sloppy state" on my pass-all rule for the GRE tunnel.
-
Someone sent me a PM on this, so a quick update is warranted :)
There is a redmine issue open on this, with no solution:
https://redmine.pfsense.org/issues/4479In most cases, I work around the issue with a quick-action floating rule with no state, all flags, outbound only on GRE interfaces, that passes all traffic coming out that interface. As this is traffic leaving pfSense, you can control which traffic leaves the interface with normal firewall rules on other nets, and inbound rules on the other side of the GRE tunnel.
Another solution, though terrible, are floating, stateless, all-flag rules both way with swapped src/dst ports (i.e. inbound from tunnel on host port 443, outbound from host port 443 to addresses across tunnel). This is obviously less than ideal because host could source any traffic at port 443 with any dst port and it could get across. Even worse the other way around, if you don't control the other tunnel endpoint.