IPv6 with HE Tunnel: ping works, but TCP fails to establish
-
what is the point of those rules on your lan below the any any for tcp to 46.101 ?? Anything below your any any rule never going to be seen..
I see no hits on your ipv6 rule in your lan?
Looks like your getting dupes of the syn,ack - so they are never seeing your ack.. Did you contact HE?
Can you post up config of your gif, and your he interface.. Your not getting any sort of IPv6 from your isp are you on your wan? Your he tunnel should be listed as default gateway in routes section you should not setup any specific gateways on any rules.
Your testing this all from pfsense, what happens when you test from client on your lan?
-
I have had the same problem since I moved. Last night I downloaded and re-flashed the very latest pfSense release just in case…
I attach 4 tcpdump run on the endpoints of attempts to run ssh by way of an HE tunnel terminated on my pfSense firewall. SYN and Reset packets get through but the conversation gets no further
It may or may not be relevant that I'm connecting to an HE server in London 216.66.80.26, and it appears that the missing packets are disappearing before being delivered to my pfSense down the HE tunnel
SSH_to_Internet_Source.txt
SSH_to_Internet_Dest.txt
SSH_from_Internet_Source.txt
SSH_from_Internet_Dest.txt -
me too, my he.net ipv6 not work now. I had use he.net ipv6 with pfsense years. but this pf 2.3.1-2.3.2 version not normal work.
-
My system is working perfectly. I had to reboot the modem a few days ago and it came back up on its own. I'm currently running 2.3.1-RELEASE-p5.
-
After much Googling, I have now a suspicion that this has something to do with my ISP (UK Sky Fiber) or the router it provides (SR102): http://helpforum.sky.com/t5/Fibre/Hurricane-electric-IPv6-Tunnel-Broker-on-BSkyB/td-p/2366610. That would probably explain the missing ACK when connecting to remote sites, if the router/ISP is dropping it. However, it's not apparent why the incoming connection behaves strangely: the WAN port does receive the tunneled TCP handshake packets, but pfsense is not passing them through to gif0. Unless maybe the packet is mangled somehow by the ISP causing pfsense to consider it invalid and drop it?
I'm attaching pcap files on the WAN & gif0 interfaces for the incoming connection case, which are what the screenshots in #1 are based on.
-
After discussing with Alex of HE I dropped the MSS way down to no avail.
I then switched to HE's other London Tunnel server, again no joy
I can ping6 and traceroute6 (ie ICMP and UDP), and syn packets get through. However using the pfSense packet Capture on the tunnel I only get the inbound SYN packet, followed by the target host sending syn-ack packets back to the initiator, which does receive them, and sends an ack which does not appear in the tunnel packet capture.
I get no further traffic from the initiator of the connection INBOUND from HE
-
After discussing with Alex of HE I dropped the MSS way down to no avail.
I then switched to HE's other London Tunnel server, again no joy
I can ping6 and traceroute6 (ie ICMP and UDP), and syn packets get through. However using the pfSense packet Capture on the tunnel I only get the inbound SYN packet, followed by the target host sending syn-ack packets back to the initiator, which does receive them, and sends an ack which does not appear in the tunnel packet capture.
I get no further traffic from the initiator of the connection INBOUND from HE
weird… maybe it is your ISP? I have no problems with pfSense and he.net tunnels in NYC
-
More weird, because : The 'tunnel' to London, UK 216.66.80.26 is nothing less or more as a TCPv4 stream, which contains the IPv6 connection.
Your ISP is filtering these kind of packets ?
Did you check your modem / device that coverts your local Ethernet to the cable / phone (ADSL) / whatever ? -
My ISP decided they could supply IPv6 directly (Zen Internet) so I've now dropped the HE tunnel in favour of native support. Sorry if that means I'm not helping others to resolve the issue, but for me it is a satisfactory outcome.
Thanks everyone for the help and support
-
Some updates:
I recently switched to a new ISP (BT Infinity) so decided to give this another go. Unfortunately the exact same ACK dropping issue still happens with BT's Smart Hub (Home Hub 6A). This time I come across this post https://ttlexpired.co.uk/2016/02/12/ipv6-tunnel-and-failing-tcp-sessions/ describing a very similar issue from an engineer working for SKY and he concluded this is a bug with Broadcom SoC's "flow cache" mechanism, and by disabling flow cache the issue can be mitigated. Both my old SKY router SR102 and BT's new hub use Broadcom's SoC, so I have a strong suspicion that this is indeed the root cause.
I'm no longer with SKY so can't experiment with it, but for anyone stumbling across this post via Google, you might be able to play with it by compiling your own SR102 firmware from SKY's GPL tarball and try to disable flow cache. Unfortunately BT has yet to release the source code for its Smart Hub, so I'm still stuck.
