Packets not forwarding through VPN

[el_baby]

Hi,

I'm migrating an old OpenVPN server (up and running now) to a new virtual machine with an updated configuration. The main difference (apart from debian and openvpn versions) is that the old one used the default topology net30 and trafic was masqueraded behind the server address, and the new one uses topology subnet and trafic is routed through the server keeping the addresses from each client within the vpn.

The server is running on a (Proxmox) VM behind the firewall, and I have an isolated VLAN from the server to the firewall so I can control also what comes in from the VPN to our serveral internal networks. Although I also have enabled a default route through the firewall and outgoing trafic is allowed, we usually configure the client to only route local traffic through the VPN and use its own default route to the internet.

The other difference in the old server was that instead of an isolaged VLAN, we had a physical cable running from the Proxmox server running the VM to the firewall.

Now, the problem I have is that I connect to the VPN but I can't reach pass the server even when routes are pushed, ip forwarding enabled in the kernel and allowed in netfilter.

I checked using tcpdump in the openvpn server and I see the traffic coming in through tun0 but not going out on ens19 (so it is not a problem with my external firewall).

This is openvpn 2.6.3 running on debian 12.

Here's the server configuration file:

[oconf=Server Config]# This is a comment


Here's the server configuration file:

mode server
tls-server
dev tun

server 172.71.1.0 255.255.255.0
topology subnet

proto udp
port 1194

cipher AES-256-CBC

#verify-client-cert optional
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key
dh /etc/openvpn/keys/dh.pem
keepalive 10 120

push "route 172.27.100.0 255.255.255.0"
push "route 172.27.101.0 255.255.255.0"

# En VPN infra agregamos más rutas
# VPN users vieja GW
push "route 172.29.30.0 255.255.255.252"
​# VPN-USERS-LEGACY-GW
push "route 172.72.0.0 255.255.255.252"
# VPN-USERS-LEGACY-LAN
​push "route 172.72.1.0 255.255.255.0"
​
push "dhcp-option DNS 172.27.101.101"
push "dhcp-option DOMAIN siu.edu.ar"
push "dhcp-option DOMAIN cin.edu.ar"

#Habilitar puerto para interfaz administrativa 17562
management 0.0.0.0 17562
​
​log-append .../openvpn.log
verb 3

​

(imagine the path in log-append... there is a big problem with the forum, I can't evn type the path without getting the 403 error)

[el_baby]

All forwarding traffic accepted:

$ sudo iptables -L -v
Chain INPUT (policy ACCEPT 85913 packets, 7006K bytes)
pkts bytes target prot opt in out source destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- tun0 ens19 anywhere anywhere
0 0 ACCEPT all -- ens19 tun0 anywhere anywhere

Chain OUTPUT (policy ACCEPT 85244 packets, 5633K bytes)
pkts bytes target prot opt in out source destination

No NAT:

$ sudo iptables -t nat -L -v
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Kernel forwarding enabled:

$ cat /proc/sys/net/ipv4/ip_forward
1

Routes:

$ ip route
default via 172.71.0.1 dev ens19 onlink
172.71.0.0/30 dev ens19 proto kernel scope link src 172.71.0.2
172.71.1.0/24 dev tun0 proto kernel scope link src 172.71.1.1

[openvpn_inc]

Hey baby!

Um, this probably does not answer your question at all, but please note that RFC 1918 does not include all of 172/8; it is only 172.16/12. This works out to 172.16.0.0 through 172.31.255.255. The 172.71 network you're using belongs to Cloudflare. (Coincidentally this forum is hosted through a Cloudflare proxy.) The other non-1918 network 172.72 belongs to Charter Communications. To you and your users this means that while connected to your VPN, they would be unable to reach some Cloudflare and Charter sites.

You definitely need to fix that.

Regarding the 403, note that this forum is new and maybe not fully working yet. But the use of Cloudflare's IP address space could cause unexpected problems.

Your issue most likely is shown by the 0:0 counters in the FORWARD chain. Typically that can mean IP forwarding is not enabled, but it also could mean clients simply are not configured to route packets through you. Check routing on the client side.

BTW recent Debian has changed from iptables to nftables. Unless you selected iptables-legacy in place of iptables-nft with update-alternatives(8), you are actually entering nftables rules. If something else is managing the firewall you might have other rules there. So check

nft show ruleset

to find out.

If you are going to use iptables-legacy (and there is nothing wrong with that choice!) you should show

iptables-save -c

to show your rules.

hth, regards, rob0

[el_baby]

Um, this probably does not answer your question at all, but please note that RFC 1918 does not include all of 172/8; it is only 172.16/12. This works out to 172.16.0.0 through 172.31.255.255. The 172.71 network you're using belongs to Cloudflare. (Coincidentally this forum is hosted through a Cloudflare proxy.) The other non-1918 network 172.72 belongs to Charter Communications. To you and your users this means that while connected to your VPN, they would be unable to reach some Cloudflare and Charter sites.

YOU'RE RIGHT! What a fool of me. I'll change that next time in the office (I have to change routing in the firewall and I try not to do those things remotely unless it is an emergency).

Regarding the 403, note that this forum is new and maybe not fully working yet. But the use of Cloudflare's IP address space could cause unexpected problems.

Quite likely. I was at the office while posting last Thursday so it might well be a problem with that.

Your issue most likely is shown by the 0:0 counters in the FORWARD chain. Typically that can mean IP forwarding is not enabled, but it also could mean clients simply are not configured to route packets through you. Check routing on the client side.

Forwarding is enabled in the server

$ cat /proc/sys/net/ipv4/ip_forward
1

Routes also seem to be right in the client:

$ ip route
default via 192.168.82.250 dev wlp2s0 proto dhcp metric 600
10.0.0.0/8 dev tun0 scope link
169.254.0.0/16 dev wlp2s0 scope link metric 1000
172.27.100.0/24 via 172.71.1.1 dev tun0 proto static metric 50
172.27.101.0/24 via 172.71.1.1 dev tun0 proto static metric 50
172.29.30.0/30 via 172.71.1.1 dev tun0 proto static metric 50
172.71.1.0/24 dev tun0 proto kernel scope link src 172.71.1.2 metric 50
172.72.0.0/30 via 172.71.1.1 dev tun0 proto static metric 50
172.72.1.0/24 via 172.71.1.1 dev tun0 proto static metric 50
192.168.82.0/24 dev wlp2s0 proto kernel scope link src 192.168.82.17 metric 600
192.168.82.250 dev wlp2s0 proto static scope link metric 50
200.68.122.134 via 192.168.82.250 dev wlp2s0 proto static metric 50

(I have the client configured to only use the VPN for traffic in the networks published by it, the default route is still my home router: 192.168.82.250).

BTW recent Debian has changed from iptables to nftables. Unless you selected iptables-legacy in place of iptables-nft with update-alternatives(8), you are actually entering nftables rules. If something else is managing the firewall you might have other rules there. So check

nft show ruleset

to find out.

If you are going to use iptables-legacy (and there is nothing wrong with that choice!) you should show

iptables-save -c

to show your rules.

I'll check this also. I'm quite likely using the default nftables but configured it like it was in the previous (older) server which is likely using iptables.

Thanx a lot for all your help.

I'll come back here either to report your suggestions worked or asking for more advice.