I have a network/connectivity/routing problem associated with achieving public internet connectivity through a VPN tunnel to a cloud connected server hosting a VPN server/gateway.
The Local Server is situated in a remote geography with restricted ISP options with no facility for inbound network connections [hence the need to use this architecture].
Local ISP ┌──------ wg1 10.8.90.1/24
10.8.0.2/24 network/internet │ VPN network
wg1│ xxxxxx ┌──────┴─┐
┌─┴──┐ xx xx ──────--┤ VPN gw |
| | xx xx ens3 │ |
│ ├─eno1 xx xx └────────┘
│ │ xx xx Cloud
│ │ xx xx Server
└────┘ xxxxxx [WG Server]
Local
Server
[WG Client]
The Local Server hosts a number of data services that need to be accessed remotely.
As configured, inbound connections to the Local Server work correctly. Likewise, responses from local services route correctly via the Cloud Server. Thus far, all good. What is unusual is that ‘wget’ and ‘apt update’ requests from the Local Server do not work when the VPN tunnel interface is up.
To be clear, the Wireguard Server/Client configurations have been checked correct. And the iptables SNAT/DNAT directions have also been checked correct. Both the Local Server and Cloud Server are running Ubuntu 22.04 and are fully upto date.
The guidance at https://ubuntu.com/server/docs/wireguard-vpn-defaultgw has been followed. And the netplan configuration has been checked.
With the Wireguard tunnel up, ping and traceroute tests from the Local Server route correctly as expected across the tunnel and out to the internet via the Cloud Server.
The problem appears to be specific to the Local Server Hardware/Software configuration. Tests with a similarly configured Multipass/Ubuntu client using similar connectivity works as expected with ‘wget’ and ‘apt’ requests working correctly.
My current thoughts are that problem may be one of: a specific ethernet hardware driver problem, a routing/netplan problem, or an MTU/fragmentation problem.
I’d welcome suggestions for further investigating and isolating this problem. Many thanks.
[ps. Of possible relevance, this problem also occurs when using an openvpn tunnel rather than a wireguard tunnel hence my thought that it is specific hardware/software issue related to the Local Server]