Ping OK but TCP broken

[bastianb]

Hi,

I need some help to understand this:

I have a tunnel that I used for some months and was working fine. Then I moved, I got another ISP and a new router supplied by that ISP.

Now I am trying to use that tunnel again and I can't establish a TCP connection on it.
The tunnel connects alright. I can ping the other end on IPv6, I can ping other servers with IPv6. But then when I try to establish a TCP connection it fails.
I have watched the packets and what happens is that my client, where I have the tunnel installed, sends a SYN. The server receives the SYN and sends back a SYN ACK. Then my client receives the SYN ACK and sends a ACK.
That last ACK is never received by the server. And then the server sends a duplicate SYN ACK again and again.

This is very similar to the post found here: https://ttlexpired.co.uk/2016/02/12/ipv6-tunnel-and-failing-tcp-sessions/
They found a bug in the router and then disabled a software fastpath function called “flow cache” to solve the issue.

I have no such thing in my ISP's router. So I thought that I would establish a VPN connection to another ISP and then connect to the tunnel through that connection. So technically I'm not using the IPv4 provided by that router to establish the tunnel but rather by my other ISP even though my packets physically go through the router. That may be a long shot, please correct me if I'm wrong. This solution worked. I could establish a working tunnel, with TCP connections.
So I believe the router is to blame somehow.

And then there is this other thread on pfsense forums from 3 days ago (is it a coincidence?) with the exact same issue: https://forum.pfsense.org/index.php?topic=116820.0
No solution found as of now.

I have tried with endpoints in Paris and London with the same result.

Anyone has seen this before? Any idea?
Thanks!

[detobate]

The flow cache fastpath feature isn't a feature exposed to a normal user via the web interface, it's a function of the Broadcom chipset that could only be disabled by the developers of the router.

See if you can find out the techspecs of your router and see if it's the same BCM63XX based Broadcom chip as that mentioned on the blog you linked.

Encapsulating the 6in4 proto41 traffic inside another VPN could indeed bypass the bug if it's the same one.

[vsauer]

I might have the same problem:

https://forums.he.net/index.php?topic=3746.0

[matthiaspfaller]

Hi,

<aol>me too</aol>

I have this problem since a couple of month. Its just that at first I didn't blame the tunnel... I lowered my tunnel MTU to 1280, but it didn't change anything. My endpoint is tserv1.fra1.he.net. I'm connected via GPON/FTTH. So no DSL at all.

Matthias

[vsauer]

I could solve this issue for the specific case of VDSL2 with FritzBox 7430 (Broadcom Chip) in modem/bridge mode.
See here:
https://forums.he.net/index.php?topic=3746.msg21104#msg21104

Do know if this could happen with FTTH as well.
Maybe you should check the hardware.
At least in my case, there was no more explanation left then a bug below layer 2.

[matthiaspfaller]

This bug is confirmed by AVM. According to the mail I got it is fixed in the beta firmware. My test indicates the same. And yes, this bug hits with FTTH as well.

[vsauer]

Here's the detailed report and solution:

https://forums.he.net/index.php?topic=3746.msg21104#msg21104

I can definitly recommend this Zyxel VMG1312-B30A over the AVM products.

[porjo]

I stumbled upon this post after experiencing the exact same symptoms and wasting several hours in frustration. I'm astonished to hear that a modem setup in bridging mode could interfere in this way!!?? :o My modem is a Netcomm NF10WV VDSL2 modem setup in bridging mode paired with an OpenWRT router. Now to find a different modem to test the theory...