TLS Handshake resets for some web sites when using OpenWRT router

5

1

Currently I'm facing a very strange issue with my router. I have TP-Link TL-WDR4300 rev. 1.7 running OpenWRT 18.06.1.

The problem originally started 1-2 months ago, when I had OpenWRT 15.05, and the last configuration change (before upgrade to 18.06.1) on the router was about a year ago.

So, 1-2 months ago I noticed that some web sites do not load on ALL devices (iPhone with iOS, Android phone, Ubuntu laptop, Windows laptop) in ALL browsers. However, if the device is disconnected from WiFi and uses, for example, cellular network, the web site loads immediately.

My ISP is Deutsche Telekom, and a good example of a web site that is not loading is https://telekom.de, which usually is expected to be reachable.

I have performed upgrade to the latest stable OpenWRT release and started investigation of the issue. There are no dropped packets in logs or any other error messages on the router that are related to the issue. Curl is able to get the content of one affected web site (telekom.de) directly on the router:

 root@OpenWrt:~# curl --tlsv1.0 -v https://telekom.de
 > GET / HTTP/1.1
 > Host: telekom.de
 > User-Agent: curl/7.60.0
 > Accept: */*
 > 
 < HTTP/1.1 301 Moved Permanently
 < Date: Sat, 01 Sep 2018 20:56:23 GMT
 < Server: Apache
 < Location: https://www.telekom.de/start
 < Content-Length: 236
 < Content-Type: text/html; charset=iso-8859-1
 < 
 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
 <html><head>
 <title>301 Moved Permanently</title>
 </head><body>
 <h1>Moved Permanently</h1>
 <p>The document has moved <a href="https://www.telekom.de/start">here</a>.</p>
 </body></html>

On all clients it still did not work:

$ curl --tlsv1.0 -v https://telekom.de
* Rebuilt URL to: https://telekom.de/
* Hostname was NOT found in DNS cache
*   Trying 46.29.100.76...
* Connected to telekom.de (46.29.100.76) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* Unknown SSL protocol error in connection to telekom.de:443 
* Closing connection 0
curl: (35) Unknown SSL protocol error in connection to telekom.de:443

I tried connecting Windows laptop directly to the PPPoE fiber optic modem of Deutsche Telekom and web sites started to load normally. I have also turned a Windows laptop into WiFi router and all the clients were able to load problematic web sites.

My original idea was that the problem may be related to IPv6 (another possibly related issue is here), and I have configured it (before it was not properly configured). It did not help, and also disabling IPv6 in the adapter settings for Windows client does not help.

When using OpenWRT as a router, the browser tries to perform a TLS handshake for a while (1-2 minutes) and then shows "secure connection failed" message.

Here is the Wireshark capture of TLS handshake for telekom.de.

And below are some of my router settings:

Screenshot of interfaces:

Interfaces

Output of iptables -L -v (I do not use standard OpenWRT firewall configuration, since it contains a lot of chains and is too complicated for me, so I rewrite it at boot via iptables-restore command):

Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination         
5651  481K ACCEPT     all  --  lo     any     anywhere             anywhere            
137K   17M ACCEPT     all  --  any    any     anywhere             anywhere             ctstate RELATED,ESTABLISHED
184  10370 logdrop    all  --  any    any     anywhere             anywhere             ctstate INVALID
0     0    ACCEPT     udp  --  pppoe-wan any     anywhere             anywhere             udp dpt:bootpc
0     0    ACCEPT     udp  --  l2tp-voip any     anywhere             anywhere             udp dpt:bootpc
67318 4219K ACCEPT     all  --  br-lan any     anywhere             anywhere            
5423  290K logdrop    all  --  any    any     anywhere             anywhere            

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination         
423K   49M ACCEPT     all  --  br-lan pppoe-wan  anywhere             anywhere            
0      0   ACCEPT     all  --  br-lan l2tp-voip  anywhere             anywhere            
0      0   ACCEPT     all  --  br-lan br-lan  anywhere             anywhere            
1324K 1610M ACCEPT     all  --  pppoe-wan br-lan  anywhere             anywhere             ctstate RELATED,ESTABLISHED
0      0   ACCEPT     all  --  l2tp-voip br-lan  anywhere             anywhere             ctstate RELATED,ESTABLISHED
0      0   logdrop    all  --  any    any     anywhere             anywhere            

Chain OUTPUT (policy ACCEPT 188K packets, 25M bytes)
pkts bytes target     prot opt in     out     source               destination         

Chain logdrop (3 references)
pkts bytes target     prot opt in     out     source               destination         
5607  300K LOG        all  --  any    any     anywhere             anywhere             LOG level warning prefix "dropped: "
5607  300K DROP       all  --  any    any     anywhere             anywhere

Output of iptables -t nat -L -v:

Chain PREROUTING (policy ACCEPT 59800 packets, 4849K bytes)
pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 39692 packets, 2880K bytes)
pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 29226 packets, 2171K bytes)
pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 2123 packets, 232K bytes)
pkts bytes target     prot opt in     out     source               destination         
35523 2660K MASQUERADE  all  --  any    pppoe-wan  anywhere             anywhere            
2  1098 MASQUERADE  all  --  any    l2tp-voip  anywhere             anywhere

Contents of /etc/config/network:

cat /etc/config/network

config interface 'loopback'
 option ifname 'lo'
 option proto 'static'
 option ipaddr '127.0.0.1'
 option netmask '255.0.0.0'

config globals 'globals'
 option ula_prefix 'xxxx:xxxx:xxxx:xxxx::/64'

config interface 'lan'
 option ifname 'eth0.1'
 option type 'bridge'
 option proto 'static'
 option ipaddr '192.168.x.x'
 option netmask '255.255.255.0'
 option ip6addr 'xxxx:xxxx:xxxx:xxxx::1/64'

config interface 'wan'
 option proto 'pppoe'
 option password 'yyyyyyyy'
 option ifname 'eth0.7'
 option username 'zzzzzzzzzzzzzzzzzzzzzzzzzzz@t-online.de'
 option ipv6 '1'

config interface 'wan6'
 option ifname '@wan'
 option proto 'dhcpv6'
 option reqprefix 'auto'
 option reqaddress 'try'

config switch
 option name 'switch0'
 option reset '1'
 option enable_vlan '1'

config switch_vlan
 option device 'switch0'
 option vlan '1'
 option vid '1'
 option ports '0t 2 3 4 5'

config switch_vlan
 option device 'switch0'
 option vlan '3'
 option vid '7'
 option ports '0t 1t'

config interface 'voip'
 option proto 'l2tp'
 option server 'ooo.ooo.ooo.ooo'
 option username 'xxxxxxxxxxx'
 option password 'xxxxxxxxxxx'
 option defaultroute '0'
 option peerdns '0'
 option delegate '0'
 option ipv6 '0'

config route
 option interface 'voip'
 option target 'xxxxxxxxxxxxxxx'
 option netmask 'xxxxxxxxxxx'
 option gateway 'xxxxxxxxxx'

What can be a reason for this problem?

Update: Following suggestions from similar question, I tried to set different MTUs (1400,1476,1480) for pppoe-wan (ifconfig pppoe-wan mtu xxxx). Unfortunately, it did not help.

Update 2: On ubuntuforums.org, a similar problem was fixed via reinstalling Ubuntu. I have just tried to re-flash OpenWRT (following https://openwrt.org/toh/tp-link/tl-wdr4300#flash_overwrite; then I applied my configuration). Unfortunately it did not help.

Andrey Sapegin

Posted 2018-08-30T21:00:13.470

Reputation: 88

2"I do not use standard OpenWRT configuration" and what happens when you backup your config, factory default it, and use the default Luci iptables rules? – Tim_Stewart – 2018-08-30T22:32:47.643

In your excerpt, curl is trying to use SSLv3. SSLv3 is dead. It is most likely totally unrelated to your router. – Daniel B – 2018-08-31T09:08:19.210

@Daniel B, thank you, I have updated the question and put there output of curl with TLS 1.0 – Andrey Sapegin – 2018-09-01T07:36:47.900

--tlsv1.0 is now deprecated. Please replace in your post the output of curl on a client and the Wireshark capture by one using --tlsv1.2 or at least --tlsv1.1. – harrymc – 2018-09-02T07:26:11.000

The Wireshark capture was done for Firefox on Windows. If I try curl with --tlsv1.2 or --tlsv1.1, the output is absolutely the same. – Andrey Sapegin – 2018-09-02T10:29:46.337

Nice detail!!!!!! – Pimp Juice IT – 2018-09-02T16:53:54.757

Does the default config work? – SILENT – 2018-09-02T23:38:02.370

Answers

3

This seems to be an issue with MTU and fragmentation. Ethernet MTU is 1500, while PPPoE MTU is (1500-8) = 1492.

Setting the MTU on the router alone doesn't help. You reduce set the MSS size in outgoing packets.

Add this rule to iptables, assuming ppp0 is your PPPoE interface:

-A FORWARD -o ppp0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

An alternative is a fixed size:

-A FORWARD -o ppp0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1400

RalfFriedl

Posted 2018-08-30T21:00:13.470

Reputation: 1 370

Yes, you are right! I have just found it myself, and will provide another answer with more details on the issue. You still get the accepted answer and all bounty points, thanks a lot! – Andrey Sapegin – 2018-09-03T20:49:41.520

2

As RalfFriedl already wrote, it is indeed the MTU problem. However, the simple change of MTU does not help. PPPoE always has less MTU the Ethernet, e.g. Ethernet MTU 1488 --> PPPoverEthernet MTU 1480. Somehow, even if the router knows the right MTU for PPPoE, and it will work in case the connection is initiated from the router itself, all client machines will still send packets with MTU 1500 and iptables needs to know that MTU adjustment is needed while forwarding the packets.

Here is the detailed description of the problem: It's 2017—Why do I Still Have to Care About MTU?

By default, OpenWRT has a special option to mitigate this issue:

However, even with non-stadard iptables rules, this can be easily fixed using --set-mss option in iptables

The important point is that this mss clamping rule should be in the beginning of FORWARD rules, to avoid packets be captured by other rules before (e.g., conntrack rules etc.)

In my case, this is the first rule there:

-A FORWARD -i br-lan -o pppoe-wan -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Andrey Sapegin

Posted 2018-08-30T21:00:13.470

Reputation: 88

Asked: 2018-08-30T21:00:13.470

Viewed: 986 times

Active: 2018-09-03T21:12:35.083