2.7.2-RELEASE GRE Tunnel problem
-
Testing a local tunnel, between 2.7.0 and 2.7.2 on the LAN works fine. So, there is something I'm not understanding about the WAN interface (which, in my case, is a VLAN on a 10g port, ix1.35.)
The test GRE tunnel was configured on ix1.1, and works as expected.
-
I assume you don't see anything blocked in the logs?
If you're running that pcap on the VLAN interface then it must be arriving there as expected. I would try a pcap on ix1 directly though to check the VLAN tags are correct in there.
-
Excellent suggestion - but they are for sure arriving on the correct vlan, and into the ix1.35 interface.
Nothing is blocked in the logs. The "firewall" entry is simply "Pass ipv4+ipv6 any protocol, any address" for both the GRE interface and the WAN interface.
I've demonstrated (to myself) that I can build a function GRE tunnel on the LAN interface, without issue, to another pfSense box, and bring it up.
I've confirmed that the GRE interface looks correct:
gre0: flags=1008051<UP,POINTOPOINT,RUNNING,MULTICAST,LOWER_UP> metric 0 mtu 1476
description: ATTtoEdge3
options=80000<LINKSTATE>
tunnel inet 1.1.1.1 --> 2.2.2.2
inet 172.17.1.226 --> 172.17.1.225 netmask 0xfffffffc
inet6 fe80::2e0:67ff:fe27:6d54%gre0 prefixlen 64 scopeid 0x12
inet6 2001:[blah]::1:2 --> 2001:[blah]::1:1 prefixlen 128
groups: gre
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>It's exactly as if the packets arrive on the WANATT interface, and can't figure out where to go to get to the GRE interface, so get discarded. I've even tried turning off hardware checksum, just in case that was breaking something.
Is there a way to trace the flow of the packets internally on FreeBSD? Adding additional rules? I'm comfortable with any outlandish suggestions anyone can offer.
-
Following on to your suggestion, I removed the ix1.35 interface, and connected it directly using a 1g Ethernet port on the 2.7.2-RELEASE router, eliminating the potential VLAN processing error.
First, I nuked the existing WAN and GRE configuration, and deleted ix1.35.
So now I have external WAN -> igc3 (1g port).I configured the igc3 port as WANATT, using DHCP and DHCP6, and ticked (only) the block private/block bogon to create default rules.
I then built the GRE tunnel. Then I added the GRE tunnel as a new interface, did not tick the "block private networks and bogon" boxes.
I then added appropriate PASS rules.
Exactly the same issues, and the same "state":
WANATT gre 1.1.1.1 -> 2.2.2.2 SINGLE:NO_TRAFFIC 1.521K / 0 94 KiB / 0 BSame traffic reaching the CIsco side, same responses coming in via igc3:
listening on igc3, link-type EN10MB (Ethernet), snapshot length 262144 bytes
04:04:43.607766 IP 1.1.1.1 > 2.2.2.2: GREv0, length 33: IP 172.17.1.226 > 172.17.1.225: ICMP echo request, id 32511, seq 7, length 9
04:04:43.607773 IP 1.1.1.1 > 2.2.2.2: GREv0, length 53: IP6 2001:[blah]::1:2 > 2001:[blah]::1:1: ICMP6, echo request, id 32912, seq 7, length 9
04:04:43.632239 IP 2.2.2.2 > 1.1.1.1: GREv0, length 33: IP 172.17.1.225 > 172.17.1.226: ICMP echo reply, id 32511, seq 7, length 9
04:04:43.633238 IP 2.2.2.2 > 1.1.1.1: GREv0, length 53: IP6 2001:[blah]::1:1 > 2001:[blah]::1:2: ICMP6, echo reply, id 32912, seq 7, length 9
04:04:44.118472 IP 1.1.1.1 > 2.2.2.2: GREv0, length 53: IP6 2001:[blah]::1:2 > 2001:[blah]::1:1: ICMP6, echo request, id 32912, seq 8, length 9
04:04:44.128981 IP 1.1.1.1 > 2.2.2.2: GREv0, length 33: IP 172.17.1.226 > 172.17.1.225: ICMP echo request, id 32511, seq 8, length 9
04:04:44.143506 IP 2.2.2.2 > 1.1.1.1: GREv0, length 53: IP6 2001:[blah]::1:1 > 2001:[blah]::1:2: ICMP6, echo reply, id 32912, seq 8, length 9
04:04:44.153758 IP 2.2.2.2 > 1.1.1.1: GREv0, length 33: IP 172.17.1.225 > 172.17.1.226: ICMP echo reply, id 32511, seq 8, length 9 -
Hmm, is that new test tunnel still to the Cisco device? Can you test to a remote pfSense device on the WAN?
For some reason the state is not matching the incoming packets. That could be because the gre interface itself is not recognising those as valid.
The gre interface has a few options that could potentially be an issue though I'm not aware of anything that changed from 2.7.0 to 2.7.2.
I would open those packets in wireshark and compare them in detail with the working LAN side tunnel.
Nothing significant I see here: https://github.com/pfsense/FreeBSD-src/commits/devel-main/sys/net/if_gre.c
-
@stephenw10
That's a great idea!I created a tunnel from 2.7.2 to the old 2.7.0 system, using the WAN interfaces.
Guess what?
Works fine.
WANATT gre 3.3.3.3 -> 1.1.1.1 MULTIPLE:MULTIPLE 512 / 344 28 KiB / 18 KiB
I can ping both sides.
I did just IPv4, initially. Let me add ipv6...And that breaks it, but IPv4 still works. So it does look line an issue... I'll continue poking.
-
@DaveRand
The IPv6 breakage was caused by the firewall entry on the GRE not permitting IPv6.So, GRE via WAN to older pfSense boxes work.
GRE from older boxes to Cisco works.
GRE from 2.7.2 to Cisco boxes work, but 2.7.2 fails to recognize the GRE packets from Cisco
GRE from 23.09.1 to older pfSense boxes works.
GRE from 23.09.1 to Cisco boxes work, but 23.09.1 fails to recognize the GRE packets from Cisco.I think there may be a bug.
-
Yup, possibly.
I would compare the gre reply packets from pfSense to those from Cisco coming into the 2.7.2 (or 23.09.1) install and see what the difference is. There must be some reason the interface isn't seeing those incoming packets.
-
@stephenw10
The problem was due to an AT&T modem keeping an ARP cache alive far longer than is reasonable. It was sending packets to the wrong MAC address. That's why the interface was seeing the traffic (promiscuous mode), but not accepting it.Sigh.
I never would have suspected it. Netgate TAC rocks.
-
Aha, nice!
