2

This question was marked off-topic on Super User, so i assume this is more suitable community for my problem.

Problem

Ever since I set up Wireguard on my Google VPS every client HTTPS connection to any Google site (search engine, YouTube, etc.) times out on TLS handshake. There is no problem with pinging, curling http://google.com or HTTPS on other sites. What can be the cause of this problem and how can I solve it?

Example

$ curl -v https://google.com

*   Trying 172.217.23.110:443...
* TCP_NODELAY set
* Connected to google.com (172.217.23.110) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* OpenSSL SSL_connect: Connection reset by peer in connection to google.com:443
* Closing connection 0
curl: (35) OpenSSL SSL_connect: Connection reset by peer in connection to google.com:443

Server config:

[Interface]
Address = 192.168.3.1/32
ListenPort = 51820
PrivateKey = <server private key>

PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o ens4 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
PublicKey = <client public key>
AllowedIPs = 192.168.3.2/32

Client config

[Interface]
Address = 192.168.3.2
PrivateKey = <client private key>
DNS = 1.1.1.1

[Peer]
PublicKey = <server public key>
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = <server address>:51820
iXerK
  • 21
  • 2
  • Do any common websites work? For example, https://serverfault.com? Maybe compare notes to how I setup WireGuard on GCP: https://wireguard.how/server/google-cloud-platform/ – Jacob Mar 03 '20 at 06:19
  • 2
    I somewhat resolved my issue. For some reason `wg-quick` set up an interface with a really low MTU. Since I've changed it in WireGuard's configuration everything seems to work. Now I am trying to better understand this issue before posting the answer. – iXerK Mar 09 '20 at 01:18
  • It'll be great to see your answer. – Serhii Rohoza Aug 05 '20 at 14:19

3 Answers3

2

As it was confirmed by @iXerK in the comment section the issue has no relation to GCP and was caused by low interface MTU:

For some reason wg-quick set up an interface with a really low MTU. Since I've changed it in WireGuard's configuration everything seems to work.

Serhii Rohoza
  • 1,424
  • 2
  • 5
  • 15
0

I was having the same problem. Some sites were not opening in the browser and the wget command was getting errors like this:

Unable to establish SSL connection.

After following these steps, the problem was solved:

  1. Run the command ip a on the WireGuard server and note the MTU size for the WireGuard interface (wg0 in this example):

     [...]
     8: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1380 qdisc [...]
     [...]
    
  2. Edit /etc/wireguard/wg0.conf file on the client and add a configuration line like this under section [Interface]:

     MTU = 1380
    

    Here the number 1380 should be the same (or lower) as obtained in the first step.

  3. Restart the interface on the client:

     wg-quick down wg0 ; wg-quick up wg0
    
FedKad
  • 113
  • 5
0

I have a similar setup:

  • site-to-site wireguard from company network to google cloud
  • in google cloud we have a small linux VM running wireguard and firewalld
  • we use this wireguard connection only to reach services in google cloud
  • we added routes to forward private IP's inside google network though the wireguard server

Connections work, but TLS doesn't without adjusting MTU and adding an iptables rule in the wireguard setup on the google cloud side:

[Interface]
Address = ...
PostUp = iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
PostDown = iptables -D FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
PrivateKey = ...
MTU = 1200

This MTU is smaller then the recommended value 1280, but we had problems with some traffic, even if TLS was working with 1280.

We do not (yet) route IPv6 over this connection. IPv6 might require larger MTU.

I do not understand why we need such a low MTU. With other wireguard tunnels (remote workers to company network), we do not have any issues.