I am not sure when it happened but VPN stopped routing traffic. I believe it happened in some recent update. I tried uninstalling and reinstalling the openvpn package but I had no luck. The VPN gateway is responding and openvpn connects correctly, but once connected I can’t access interal servers or browse the web
EDIT: Apparently I had the wireguard package installed. I removed the package but the interface is still there
EDIT2: Uninstalling all wireguard packages and I don’t see the interface or the routing entry
Here is my routing table
root@DietPi:~# route -v
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 192.168.31.1 0.0.0.0 UG 0 0 0 eth0
10.6.0.0 0.0.0.0 255.255.255.0 U 0 0 0 wg0
10.8.0.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0
10.8.0.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
192.168.31.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
One thing is that the routing table shows that the default gateway is using .31.1, which I presume is your ISP router.
Second thing is that to use the vpn from other devices, traffic must be masqueraded on tun0 interface. Verify with iptables-save -c -t nat
Third, the forwarding must be enabled, verify with cat /proc/sys/net/ipv4/ip_forward
There is a route for the internal network .31.0/24, so you should be able to access the other devices in that lan.
dietpi@DietPi:~$ cat /proc/sys/net/ipv4/ip_forward
1
dietpi@DietPi:~$ sudo iptables-save -c -t nat
# Generated by xtables-save v1.8.2 on Sat Nov 20 17:23:39 2021
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT
# Completed on Sat Nov 20 17:23:39 2021
I keep connecting but without browsing… the weird thing is that installing the wireguard package and pivpn package works perfectly both with wireguard and openvpn backend. The standalone openvpn does not
I am trying to setup that a hardware router does use the openvpn connection and it only seems to connect if I am using the standalone openvpn package, wireguard is not supported and with pivpn there are some errors and the connection is not established
There is still something wrong with your configuration. The default gateway is the ISP router. Furthermore tun0 has 0 received (RX) packets, which means it is not working properly. Post the log from OpenVPN to see what the problem might be. Also verify which DNS is used.
The connection from my mobile (in 4G) to the VPN is good, it connects. But I can’t seem to reach the internal network. I think it’s something related with iptables? as forwarding is enabled
From OpenVPN logs I can see only status.log which is blank
If I start OpenVPN via command line and connect from mobile this happens
root@DietPi:/etc/openvpn# /usr/sbin/openvpn --status /run/openvpn/server.status 10 --cd /etc/openvpn --config /etc/openvpn/server.conf --writepid /run/openvpn/server.pid
Sun Nov 21 00:54:43 2021 OpenVPN 2.4.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Apr 28 2021
Sun Nov 21 00:54:43 2021 library versions: OpenSSL 1.1.1d 10 Sep 2019, LZO 2.10
Sun Nov 21 00:54:43 2021 Diffie-Hellman initialized with 2048 bit key
Sun Nov 21 00:54:43 2021 ROUTE_GATEWAY 192.168.31.1/255.255.255.0 IFACE=eth0 HWADDR=20:47:47:ed:9f:ea
Sun Nov 21 00:54:43 2021 TUN/TAP device tun0 opened
Sun Nov 21 00:54:43 2021 TUN/TAP TX queue length set to 100
Sun Nov 21 00:54:43 2021 /sbin/ip link set dev tun0 up mtu 1500
Sun Nov 21 00:54:43 2021 /sbin/ip addr add dev tun0 local 10.8.0.1 peer 10.8.0.2
Sun Nov 21 00:54:43 2021 /sbin/ip route add 10.8.0.0/24 via 10.8.0.2
Sun Nov 21 00:54:43 2021 Could not determine IPv4/IPv6 protocol. Using AF_INET
Sun Nov 21 00:54:43 2021 Socket Buffers: R=[212992->212992] S=[212992->212992]
Sun Nov 21 00:54:43 2021 UDPv4 link local (bound): [AF_INET][undef]:1194
Sun Nov 21 00:54:43 2021 UDPv4 link remote: [AF_UNSPEC]
Sun Nov 21 00:54:43 2021 GID set to nogroup
Sun Nov 21 00:54:43 2021 UID set to nobody
Sun Nov 21 00:54:43 2021 MULTI: multi_init called, r=256 v=256
Sun Nov 21 00:54:43 2021 IFCONFIG POOL: base=10.8.0.4 size=62, ipv6=0
Sun Nov 21 00:54:43 2021 Initialization Sequence Completed
Sun Nov 21 00:54:52 2021 176.80.133.166:51866 TLS: Initial packet from [AF_INET]176.80.133.166:51866, sid=f846d120 d9f17d44
Sun Nov 21 00:54:53 2021 176.80.133.166:51866 VERIFY OK: depth=1, CN=ChangeMe
Sun Nov 21 00:54:53 2021 176.80.133.166:51866 VERIFY OK: depth=0, CN=DietPi_OpenVPN_Client
Sun Nov 21 00:54:53 2021 176.80.133.166:51866 peer info: IV_VER=3.git::662eae9a:Release
Sun Nov 21 00:54:53 2021 176.80.133.166:51866 peer info: IV_PLAT=android
Sun Nov 21 00:54:53 2021 176.80.133.166:51866 peer info: IV_NCP=2
Sun Nov 21 00:54:53 2021 176.80.133.166:51866 peer info: IV_TCPNL=1
Sun Nov 21 00:54:53 2021 176.80.133.166:51866 peer info: IV_PROTO=2
Sun Nov 21 00:54:53 2021 176.80.133.166:51866 peer info: IV_LZO_STUB=1
Sun Nov 21 00:54:53 2021 176.80.133.166:51866 peer info: IV_COMP_STUB=1
Sun Nov 21 00:54:53 2021 176.80.133.166:51866 peer info: IV_COMP_STUBv2=1
Sun Nov 21 00:54:53 2021 176.80.133.166:51866 peer info: IV_AUTO_SESS=1
Sun Nov 21 00:54:53 2021 176.80.133.166:51866 peer info: IV_GUI_VER=net.openvpn.connect.android_3.2.5-7182
Sun Nov 21 00:54:53 2021 176.80.133.166:51866 peer info: IV_SSO=openurl
Sun Nov 21 00:54:53 2021 176.80.133.166:51866 peer info: IV_BS64DL=1
Sun Nov 21 00:54:53 2021 176.80.133.166:51866 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 2048 bit RSA
Sun Nov 21 00:54:53 2021 176.80.133.166:51866 [DietPi_OpenVPN_Client] Peer Connection Initiated with [AF_INET]176.80.133.166:51866
Sun Nov 21 00:54:53 2021 DietPi_OpenVPN_Client/176.80.133.166:51866 MULTI_sva: pool returned IPv4=10.8.0.6, IPv6=(Not enabled)
Sun Nov 21 00:54:53 2021 DietPi_OpenVPN_Client/176.80.133.166:51866 MULTI: Learn: 10.8.0.6 -> DietPi_OpenVPN_Client/176.80.133.166:51866
Sun Nov 21 00:54:53 2021 DietPi_OpenVPN_Client/176.80.133.166:51866 MULTI: primary virtual IP for DietPi_OpenVPN_Client/176.80.133.166:51866: 10.8.0.6
Sun Nov 21 00:54:53 2021 DietPi_OpenVPN_Client/176.80.133.166:51866 PUSH: Received control message: 'PUSH_REQUEST'
Sun Nov 21 00:54:53 2021 DietPi_OpenVPN_Client/176.80.133.166:51866 SENT CONTROL [DietPi_OpenVPN_Client]: 'PUSH_REPLY,route 10.8.0.0 255.255.255.0,topology net30,ping 10,ping-restart 60,ifconfig 10.8.0.6 10.8.0.5,peer-id 0,cipher AES-256-GCM' (status=1)
Sun Nov 21 00:54:53 2021 DietPi_OpenVPN_Client/176.80.133.166:51866 Data Channel: using negotiated cipher 'AES-256-GCM'
Sun Nov 21 00:54:53 2021 DietPi_OpenVPN_Client/176.80.133.166:51866 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Sun Nov 21 00:54:53 2021 DietPi_OpenVPN_Client/176.80.133.166:51866 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
So the problem is on a VPN server, not client to a commercial VPN. This was not clear in the description.
The server is not pushing the local network to the client, only the vpn subnet.
SENT CONTROL [DietPi_OpenVPN_Client]: 'PUSH_REPLY,route 10.8.0.0 255.255.255.0,topology net30,ping 10,ping-restart 60,ifconfig 10.8.0.6 10.8.0.5,peer-id 0,cipher AES-256-GCM' (status=1)
Thank you! Pushing the route in the server.conf works. I wonder why this worked in earlier versions of DietPi and I needed to add manually now.
I don’t get what you mean in
push "redirect-gateway def1 bypass-dhcp"
so everything is routed by the tunnel. Isn’t everything routed by the vpn tunnel when the client is connected? The idea of using this tunnel is faking that the location where I am conecting to internet is from my home instead of the place I am actually connecting ( I am using a wifi router with the vpn client enabled)
This option is not something new, I remember it for more than 15 years, so if it wasn’t there, it certainly couldn’t have worked.
Isn’t everything routed by the vpn tunnel when the client is connected?
Not by default. You can have a split tunnel (specific networks over vpn, others over regular internet) or full tunnel (all over vpn). The redirect-gateway option is for the full tunnel, which is applicable in your usecase.
I wonder if the code of the configuration file for the openvpn for dietpi is public so I can check and add the fix if it was remixed by mistake
Thank you for clarifying.
Even with the first option, when I connect to the VPN and go to what is my ip.com in the client browser the ip shown is the ip from the remote network.
Doesnt this mean that all my traffic is being routed through the VPN? Is strange to me that unless I specify any other routing, the traffic will not go though the VPN.
My final goal is to use a hardware device that has the vpn client connected, so I can connect a Windows machine to it and use the corporate VPN. For some of the companies now it won’t allow to connect unless you are in the location that they specify
We’ll need to have a look at the configuration file of the server and the client to have an idea what is going on.
With the first option of pushing a specific route to the clients only, it could work if your browser is using a proxy on the server side.
The other thing I can think of is that the server never actually sent any routes to the client, but the client was configured to send everything via the server. If that was the case, then a change in configuration from the client could have changed the behaviour.
I just wanted to add that I’ve been dealing with a similar issue. I run both wg and openvpn but every so often the servers both stop pushing networks. I can connect on both fine but nothing happens after that. no data is shown as received in the wireguard client every time this happens. previously I’ve been after to reboot the dietpi server and it seems to correct things but this seems to have stopped working possibly after the most recent updates? the last time I was able to reboot to fix was around 2 weeks ago. (im very vigilant with updates). all my other services on the dietpi box seem to work fine
Destination Gateway Genmask Flags Metric Ref Use Iface
default 172.16.0.1 0.0.0.0 UG 0 0 0 eth0
10.8.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
172.16.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
I was actually using DHCP. I’ve switched it to static inside dietpi then rebooted and it’s working again. I’ve been running this same setup for a few years I feel but never had problems until recently
No, I was just distributing the static ip through the router. Ive done this for years with the same subnet IP. I’ve now bound it on the dietpi now as well.
Hmm in this case probably the IP address assigned via DHCP did not fit to your port forwarding? At least it would need to be same target IP as on DietPi system