3

I have a very strange problem and I would like to find a starting point to solve it.

The problem appears on my laptops with Ubuntu (16.04 and 19.04) when I turn on VPN (network-manager-vpnc) but only on my parent's WiFi. And that is a super strange thing to me. When I switch to tethering on my phone then everything (except very weak GSM signal:]) is fine. Moreover it seems that problem is only with HTTPS connections. curl hangs on TLS:

$ curl https://www.onet.pl/ -v
* Expire in 0 ms for 6 (transfer 0x55cd601785c0)

... <Expire in... repeated many times>...

* Expire in 0 ms for 1 (transfer 0x55cd601785c0)
*   Trying 213.180.141.140...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55cd601785c0)
* Connected to www.onet.pl (213.180.141.140) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):

But when HTTP used:

$ curl onet.pl
<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>

it returns a response.

Any idea what may be wrong? Please let me know if you need more info to help.

  • @pLumo Not sure if I understand your question correctly but everything works fine if I connect to the VPN using any other WiFi – user2146414 Sep 4 '19 at 12:42
  • ah yeah sorry, then my comment does not apply ... – pLumo Sep 4 '19 at 12:43
  • What do you mean "turn on VPN" - do you actually connect to a VPN provider ? – Robert Riedl Sep 5 '19 at 11:02
  • @RobertRiedl Yes. I connect to my company's VPN. – user2146414 Sep 5 '19 at 13:14
  • did you have a chance to try the MTU size ? – Robert Riedl Sep 10 '19 at 6:59
2

This could be because the WI-FI router drops packets.
It happens when the size of the packets are to big.

try lowering your MTU size.

If your wifi interface name is wl0:

 sudo ifconfig wl0 mtu 1400

This setting is harmless and not persistent over reboot.
If it works and you accept the answer I will update with an explanation on why this happens :)

| improve this answer | |
  • I agree that it sounds like packets are to blame and/or it is an OSI layer 4 issue based on the description given. – Mark Sep 5 '19 at 22:51
  • before you fiddle with the MTU size, you can verify this and find out the correct size with ping pakets of a defined size...i.e. ping -M do -s 1471 www.onet.pl would send a 1479 byte (1471 + 8 bytes header) ICMP paket and allow for some VPN overhead. -M do prohibits fragmentation, so its really one paket. If this goes through, its not about the MTU size. If you get a "message too long" then you can try and go down with the 1471 value until it works. Then set the MTU size a bit lower than that. – Robert Riedl Sep 6 '19 at 7:25
  • @tomodachi Sorry for delay. This is the first time I could test your solution again. It works. Almost:) I.e. It seems that setting MTU on tun0 interface helped. If you could say something more about it it would be great:) I Hope you'll get bounty point when I accept your solution – user2146414 Oct 7 '19 at 6:43
0

If your provider is using some sort of load balancer like RouterOS PCC (Per-Connection Classifier) using both-addresses-and-ports, that could be a problem because it doesn't play well with HTTPS.

Another possible reason is a transparent proxy, when a not-so-experienced network administrator tries to do a port redirect on packets which are destined to the 443 port. But I haven't tested it through, so I'm not 100% sure if it's the case. You can check it you're passing through a proxy with a simple telnet test, as presented in here.

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.