I'm currently debugging an issue where GRE traffic is dropped at the firewall even with explicit rules to allow forwarding from WAN to LAN as well as input to the device. I've also created rules to allow all IP traffic from the source IP to make sure that nothing blocked it. Packet captures of the WAN interface show GRE protocol traffic is received but then responded to with ICMP destination unreachable. I do not see the traffic reach the LAN interface. This causes my client VPN to fail its connection.
To troubleshoot, I verified that all nathelper and GRE kernel modules are installed and verified the conntrack helpers are showing in iptables RAW table. I can post pcaps if need be.
Has anyone seen this issue occur? The build is from a trunk snapshot from a few days prior. Any help you can give will be much appreciated.
Not sure what you are trying to set up. You should not try to send raw GRE over the Internet because it is unencrypted and unathenticated.
I have two sites linked by an OpenVPN TAP tunnel (UDP connection on the Internet), and though all TCP and UDP works through this tunnel-- without any additional firewall settings, since it is a layer 2 LAN to LAN link, GRE will not. This may be a limitation of OpenVPN or something that needs to be configured in OpenVPN.
I'm just trying to use the PPTP client in Windows to connect to client sites. Unfortunately it's the only protocol option available. The PPTP traffic (TCP 1723) itself passes through the firewall in both directions without issue, but the GRE inbound traffic fails and the tunnel is never negotiated.
If I had control over what protocol my clients use, I'd migrate them in a heartbeat. As is, I just want to get it working.
Found the solution - apparently the helper conntrack module wasnt loaded automatically. Solved it by adding a line to the file /etc/sysctl.d/local.conf
net.netfilter.nf_conntrack_helper = 1
and to /etc/sysctl.conf
net.netfilter.nf_conntrack_helper = 1