I have a droplet on DigitalOcean that my router is connecting to. I am not passing all my traffic to it, just traffic to the droplet (wireguard IP 10.8.0.1) So far it seems to be working that way. From my router (10.8.0.1) I can ping 10.8.0.1 and it works just fine. In fact I can ping 10.8.0.1 from any of my machines on my local network (192.168.8.0/24). However I can’t do the reverse. From the droplet I can’t ping 10.8.0.2. At first I thought it was the wireguard settings on the droplet causing the issue. But the ping connects, it just gets 100% packet loss instead of a route not found error. This makes me think that there is a firewall on the router end that is blocking traffic coming back through the tunnel.
Is there somewhere I can look on the router to make sure there isn’t a firewall on wgclient1 that prevents incoming data from 10.8.0.1?
droplet wg0.conf
[Interface]
Address = 10.8.0.1/32
SaveConfig = true
ListenPort = 60031
PrivateKey = REDACTED
[Peer]
PublicKey = REDACTED
AllowedIPs = 10.8.0.0/24, 192.168.8.0/24
router wireguard client config
[Interface]
Address = 10.8.0.2/24
ListenPort = 60031
PrivateKey = REDACTED
[Peer]
AllowedIPs = 10.8.0.0/24
Endpoint = 137.184.4.49:60031
PersistentKeepalive = 25
PublicKey = REDACTED
I got into the LuCI and checked my routes. The one for wgclinet1 was rejecting all traffic. changed it and now I can ping between 10.8.0.1 and 10.8.0.2 just fine, however I have a different problem.
As far as I can tell the traffic to 10.8.0.1 is not all being passed through the router from certain clients.
With that change I can ping everything from everywhere in the network. And as long as the services hosted on 10.8.0.1 are http, there is no issue. But as soon as I enable https I start getting unexpected end of file errors when I try an curl a url from my linux machines. And I don’t have any windows machines to test with.
So something is interfering with the network.
curl -v https://pihole2.voh.haus
* Host pihole2.voh.haus:443 was resolved.
* IPv6: (none)
* IPv4: 10.8.0.1
* Trying 10.8.0.1:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS alert, decode error (562):
* TLS connect error: error:0A000126:SSL routines::unexpected eof while reading
* closing connection #0
curl: (35) TLS connect error: error:0A000126:SSL routines::unexpected eof while reading
Hi
If you want to access the router on the WireGuard client side from the WireGuard server side, you need to enable the following option.
Of course, in essence this is also about adjusting the firewall zones to allow forwarding from WireGuard to LAN.
As for the issue encountered with curl, it seems to be certificate-related rather than a network issue, since HTTP works normally.
You can try using the -k option to temporarily skip certificate verification and see whether it works.
curl -vvv -k https://pihole2.voh.haus
If thisi works, check whether the certificate configurations, TLS versions, etc. on both ends match.
curl --tlsv1.2 -vvv https://pihole2.voh.haus
curl --tlsv1.3 -vvv https://pihole2.voh.haus
1 Like
It looks like it was the MTU causing problems. Reducing the MTU allowed the HTTPS handshake to complete.
1 Like
