Hi, I've set up an openvpn server and I am able to connect from client but I cannot access local network of the server afterwards, I followed official documentations and searched on forums but couldn't find why I cannot reach the local network. The gateway is not on the same server as the vpn. openvpn server version is 2.4.7 (debian buster) openvpn client version is 2.5.1 (debian bullseye) server.conf [oconf=Server Config] port 1194 proto udp dev tun ca /etc/openvpn/server/ca.crt cert /etc/openvpn/server/srvkey.crt key /etc/openvpn/server/srvkey.key dh /etc/openvpn/server/dh.pem server 10.8.0.0 255.255.255.0 ifconfig 10.8.0.1 10.8.0.2 push "route 10.8.0.0 255.255.255.0" push "route 192.168.1.0 255.255.255.0" push "redirect-gateway def1 bypass-dhcp" push "dhcp-option DNS 192.168.1.1" duplicate-cn cipher AES-256-CBC tls-version-min 1.2 tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256:TLS-DHE-RSA-WITH-AES-128-GCM-SHA256:TLS-DHE-RSA-WITH-AES-128-CBC-SHA256 auth SHA512 auth-nocache keepalive 20 60 persist-key persist-tun compress lz4 daemon user nobody group nogroup log-append /var/log/openvpn.log verb 3[/oconf] client.ovpn [oconf=Server Config] client dev tun proto udp remote store.XXXX.com 1194 ca ca.crt cert client.crt key client.key cipher AES-256-CBC auth SHA512 auth-nocache tls-version-min 1.2 tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256:TLS-DHE-RSA-WITH-AES-128-GCM-SHA256:TLS-DHE-RSA-WITH-AES-128-CBC-SHA256 resolv-retry infinite compress lz4 nobind persist-key persist-tun mute-replay-warnings verb 3 script-security 2 up /etc/openvpn/update-resolv-conf down /etc/openvpn/update-resolv-conf[/oconf] server routes: root@store:~# ip route default via 192.168.1.1 dev bond0 onlink 10.8.0.0/24 via 10.8.0.2 dev tun0 10.8.0.2 dev tun0 proto kernel scope link src 10.8.0.1 172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 192.168.1.0/24 dev bond0 proto kernel scope link src 192.168.1.10 client routes when connected to vpn server: root@nexus2-bullseye-latest5:~# ip route 0.0.0.0/1 via 10.8.0.9 dev tun0 default via 10.66.51.222 dev ens2 10.8.0.0/24 via 10.8.0.9 dev tun0 10.8.0.1 via 10.8.0.9 dev tun0 10.8.0.9 dev tun0 proto kernel scope link src 10.8.0.10 10.66.51.222/31 dev ens2 proto kernel scope link src 10.66.51.223 PUB@IP via 10.66.51.222 dev ens2 128.0.0.0/1 via 10.8.0.9 dev tun0 192.168.1.0/24 via 10.8.0.9 dev tun0 I can only reach the vpn server on local network but not the other ones: root@nexus2-bullseye-latest5:~# traceroute 192.168.1.10 traceroute to 192.168.1.10 (192.168.1.10), 30 hops max, 60 byte packets 1 192.168.1.10 (192.168.1.10) 10.053 ms 10.125 ms 10.168 ms root@nexus2-bullseye-latest5:~# traceroute 192.168.1.230 traceroute to 192.168.1.230 (192.168.1.230), 30 hops max, 60 byte packets 1 10.8.0.1 (10.8.0.1) 8.876 ms 8.801 ms 8.779 ms 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * Gateway: root@gateway:~# iptables -t nat -v -L POSTROUTING -n --line-number Chain POSTROUTING (policy ACCEPT 3394K packets, 217M bytes) num pkts bytes target prot opt in out source destination 1 78M 4619M TCPMSS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcpflags: 0x06/0x02 TCPMSS clamp to PMTU 2 60M 3875M MASQUERADE all -- * eth1 0.0.0.0/0 0.0.0.0/0 3 0 0 MASQUERADE all -- * eth0 10.8.0.0/24 0.0.0.0/0 root@gateway:~# ip route default via 192.168.0.1 dev eth1 192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.5 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.1 Any help would be appreciated. Thank you

Hi fm, While we use and recommend NAT by default in Access Server and OpenVPN Cloud, for community servers I never recommend NAT. It's always best when routing from one [url=https://datatracker.ietf.org/doc/html/rfc1918]RFC 1918[/url] network to another, to simply fix the routing. You seem to be missing that basic understanding of routing. In a nutshell, packets need to know how to go in both directions. It's not enough to set routes on the VPN server: you also need for the LAN to know how to reach the VPN addresses. [url=https://www.ircpimps.org/serverlan.png]This handy flowchart[/url] tells you step-by-step how to debug the problem of being unable to reach LAN hosts behind an openvpn server. FWIW docker is a project seemingly devoid of understanding of basic routing, so they do all those stupid NAT tricks. If you want help with iptables NAT with docker, go to them for help. Also, [i]iptables -L[/i] commands suck. If I was interested in helping you solve the NAT thing I would insist on [code]iptables-save -c[/code]. (But for the record I will not help anyone with docker iptables garbage. Nothing personal.) Good luck and best regards, rob0

local network of vpn server is unreachable

fmutshe

Hi, I've set up an openvpn server and I am able to connect from client but I cannot access local network of the server afterwards, I followed official documentations and searched on forums but couldn't find why I cannot reach the local network. The gateway is not on the same server as the vpn.

openvpn server version is 2.4.7 (debian buster)
openvpn client version is 2.5.1 (debian bullseye)

server.conf

port 1194
proto udp
dev tun
ca /etc/openvpn/server/ca.crt
cert /etc/openvpn/server/srvkey.crt
key /etc/openvpn/server/srvkey.key
dh /etc/openvpn/server/dh.pem
server 10.8.0.0 255.255.255.0
ifconfig 10.8.0.1 10.8.0.2
push "route 10.8.0.0 255.255.255.0"
push "route 192.168.1.0 255.255.255.0"
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 192.168.1.1"
duplicate-cn
cipher AES-256-CBC
tls-version-min 1.2
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256:TLS-DHE-RSA-WITH-AES-128-GCM-SHA256:TLS-DHE-RSA-WITH-AES-128-CBC-SHA256
auth SHA512
auth-nocache
keepalive 20 60
persist-key
persist-tun
compress lz4
daemon
user nobody
group nogroup
log-append /var/log/openvpn.log
verb 3

client.ovpn

client
dev tun
proto udp
remote store.XXXX.com 1194
ca ca.crt
cert client.crt
key client.key
cipher AES-256-CBC
auth SHA512
auth-nocache
tls-version-min 1.2
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256:TLS-DHE-RSA-WITH-AES-128-GCM-SHA256:TLS-DHE-RSA-WITH-AES-128-CBC-SHA256
resolv-retry infinite
compress lz4
nobind
persist-key
persist-tun
mute-replay-warnings
verb 3
script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

server routes:

root@store:~# ip route
default via 192.168.1.1 dev bond0 onlink
10.8.0.0/24 via 10.8.0.2 dev tun0
10.8.0.2 dev tun0 proto kernel scope link src 10.8.0.1
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
192.168.1.0/24 dev bond0 proto kernel scope link src 192.168.1.10

client routes when connected to vpn server:

root@nexus2-bullseye-latest5:~# ip route
0.0.0.0/1 via 10.8.0.9 dev tun0
default via 10.66.51.222 dev ens2
10.8.0.0/24 via 10.8.0.9 dev tun0
10.8.0.1 via 10.8.0.9 dev tun0
10.8.0.9 dev tun0 proto kernel scope link src 10.8.0.10
10.66.51.222/31 dev ens2 proto kernel scope link src 10.66.51.223
PUB@IP via 10.66.51.222 dev ens2
128.0.0.0/1 via 10.8.0.9 dev tun0
192.168.1.0/24 via 10.8.0.9 dev tun0

I can only reach the vpn server on local network but not the other ones:

root@nexus2-bullseye-latest5:~# traceroute 192.168.1.10
traceroute to 192.168.1.10 (192.168.1.10), 30 hops max, 60 byte packets
1 192.168.1.10 (192.168.1.10) 10.053 ms 10.125 ms 10.168 ms

root@nexus2-bullseye-latest5:~# traceroute 192.168.1.230
traceroute to 192.168.1.230 (192.168.1.230), 30 hops max, 60 byte packets
1 10.8.0.1 (10.8.0.1) 8.876 ms 8.801 ms 8.779 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *

Gateway:

root@gateway:~# iptables -t nat -v -L POSTROUTING -n --line-number
Chain POSTROUTING (policy ACCEPT 3394K packets, 217M bytes)
num pkts bytes target prot opt in out source destination
1 78M 4619M TCPMSS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcpflags: 0x06/0x02 TCPMSS clamp to PMTU
2 60M 3875M MASQUERADE all -- * eth1 0.0.0.0/0 0.0.0.0/0
3 0 0 MASQUERADE all -- * eth0 10.8.0.0/24 0.0.0.0/0

root@gateway:~# ip route
default via 192.168.0.1 dev eth1
192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.5
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.1

Any help would be appreciated.

Thank you

TinCanTech

You need NAT on the VPN server also..

fmutshe

hum this is already the case:

root@store:~# iptables -t nat -v -L POSTROUTING
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 MASQUERADE all -- any !docker0 172.17.0.0/16 anywhere
0 0 MASQUERADE tcp -- any any 172.17.0.2 172.17.0.2 tcp dpt:http
0 0 MASQUERADE tcp -- any any 172.17.0.2 172.17.0.2 tcp dpt:8126
0 0 MASQUERADE udp -- any any 172.17.0.2 172.17.0.2 udp dpt:8125
0 0 MASQUERADE tcp -- any any 172.17.0.2 172.17.0.2 tcp dpt:2024
0 0 MASQUERADE tcp -- any any 172.17.0.2 172.17.0.2 tcp dpt:2023
0 0 MASQUERADE tcp -- any any 172.17.0.2 172.17.0.2 tcp dpt:2004
0 0 MASQUERADE tcp -- any any 172.17.0.2 172.17.0.2 tcp dpt:cfinger
265 16128 MASQUERADE all -- any tun0 anywhere anywhere
5513K 379M MASQUERADE all -- any bond0 anywhere anywhere

fmutshe

Anyone has an idea please? Im stucked here, don't see what I am missing.

TinCanTech

Your VPN is working normally but you don't know how to setup routing, which is documented.

If all else fails then I am available for hire.

openvpn_inc

Hi fm,

While we use and recommend NAT by default in Access Server and OpenVPN Cloud, for community servers I never recommend NAT. It's always best when routing from one RFC 1918 network to another, to simply fix the routing. You seem to be missing that basic understanding of routing.

In a nutshell, packets need to know how to go in both directions. It's not enough to set routes on the VPN server: you also need for the LAN to know how to reach the VPN addresses.

This handy flowchart tells you step-by-step how to debug the problem of being unable to reach LAN hosts behind an openvpn server.

FWIW docker is a project seemingly devoid of understanding of basic routing, so they do all those stupid NAT tricks. If you want help with iptables NAT with docker, go to them for help. Also, iptables -L commands suck. If I was interested in helping you solve the NAT thing I would insist on

iptables-save -c

. (But for the record I will not help anyone with docker iptables garbage. Nothing personal.)

Good luck and best regards, rob0

fmutshe

Thank you all for the help, I'm using routing and still not able to make it work:

server:

ip a:
bond0: <BROADCAST,MULTICAST,PROMISC,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 78:2b:cb:08:bc:38 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.10/24 brd 192.168.1.255 scope global bond0
valid_lft forever preferred_lft forever
tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
link/none
inet 172.27.224.1/20 brd 172.27.239.255 scope global tun0
valid_lft forever preferred_lft forever

root@store:~# ip route
default via 192.168.1.1 dev bond0 onlink
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
172.27.224.0/20 dev tun0 proto kernel scope link src 172.27.224.1
192.168.1.0/24 dev bond0 proto kernel scope link src 192.168.1.10

client:

root@nexus2-bullseye-latest5:~# ip route
0.0.0.0/1 via 172.27.224.1 dev tun0
default via 10.66.51.222 dev ens2
10.66.51.222/31 dev ens2 proto kernel scope link src 10.66.51.223
VPN_SERVER_PUBLIC_IP via 10.66.51.222 dev ens2
128.0.0.0/1 via 172.27.224.1 dev tun0
172.27.224.0/24 dev tun0 proto kernel scope link src 172.27.224.2

client on vpn subnet that I'm trying to reach (192.168.1.0/24):
ip of the client: 192.168.1.230

root@nexus-migration:~# ip route
default via 192.168.1.1 dev eth0 onlink
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
172.27.224.0/24 via 192.168.1.10 dev eth0
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.230

tcpdump on vpn server while pinging from vpn client to client on LAN:

root@store:~# tcpdump -n -i bond0 host 192.168.1.230
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on bond0, link-type EN10MB (Ethernet), capture size 262144 bytes
10:51:37.724983 IP 172.27.224.2 > 192.168.1.230: ICMP echo request, id 49422, seq 14, length 64
10:51:37.725482 IP 192.168.1.230 > 172.27.224.2: ICMP echo reply, id 49422, seq 14, length 64
10:51:38.748532 IP 172.27.224.2 > 192.168.1.230: ICMP echo request, id 49422, seq 15, length 64
10:51:38.749121 IP 192.168.1.230 > 172.27.224.2: ICMP echo reply, id 49422, seq 15, length 64
10:51:39.772588 IP 172.27.224.2 > 192.168.1.230: ICMP echo request, id 49422, seq 16, length 64
10:51:39.773089 IP 192.168.1.230 > 172.27.224.2: ICMP echo reply, id 49422, seq 16, length 64

OK on main interface but not on the tun0:

root@store:~# tcpdump -n -i tun0 host 192.168.1.230
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
10:51:28.508600 IP 172.27.224.2 > 192.168.1.230: ICMP echo request, id 49422, seq 5, length 64
10:51:29.532679 IP 172.27.224.2 > 192.168.1.230: ICMP echo request, id 49422, seq 6, length 64
10:51:30.556509 IP 172.27.224.2 > 192.168.1.230: ICMP echo request, id 49422, seq 7, length 64
10:51:31.580703 IP 172.27.224.2 > 192.168.1.230: ICMP echo request, id 49422, seq 8, length 64

Seems to me that the routing is correct here so I don't understand where to look next?

fmutshe

new server.conf:

port 1194
proto udp
dev tun
ca /etc/openvpn/server/ca.crt
cert /etc/openvpn/server/srvkey.crt
key /etc/openvpn/server/srvkey.key
dh /etc/openvpn/server/dh.pem
server 172.27.224.0 255.255.240.0
client-to-client
client-config-dir ccd
topology subnet
push "redirect-gateway def1 bypass-dhcp autolocal"
push "dhcp-option DNS 192.168.1.1"
duplicate-cn
#block-ipv6
route-metric 101
cipher AES-256-CBC
tls-version-min 1.2
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256:TLS-DHE-RSA-WITH-AES-128-GCM-SHA256:TLS-DHE-RSA-WITH-AES-128-CBC-SHA256
auth SHA512
auth-nocache
keepalive 20 60
persist-key
persist-tun
compress lz4
daemon
user nobody
group nogroup
log-append /var/log/openvpn.log
verb 3

300000

On my router running DDwrt it need three firewall rule to make it work

iptables -t nat -I POSTROUTING -s 10.10.50.0/24 -o `get_wanface` -j SNAT --to `nvram get wan_ipaddr`

iptables -I INPUT 2 -i tun6+ -j ACCEPT

iptables -I FORWARD 1 -i tun6+ -j ACCEPT

Your server router need NAT but router have some more rule to full pass through.

fmutshe

Thank you, after more digging and tests, I was finally able to solve it by running theses commands!

iptables -A FORWARD -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -o bond0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i bond0 -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT

which is weird because my FORWARD chain was already looking like this:

Chain FORWARD (policy DROP)
target prot opt source destination
DOCKER-USER all -- anywhere anywhere
DOCKER-ISOLATION-STAGE-1 all -- anywhere anywhere
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
DOCKER all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED

root@nexus2-bullseye-latest5:~# ping 192.168.1.230
PING 192.168.1.230 (192.168.1.230) 56(84) bytes of data.
64 bytes from 192.168.1.230: icmp_seq=1 ttl=63 time=13.6 ms
64 bytes from 192.168.1.230: icmp_seq=2 ttl=63 time=24.7 ms
64 bytes from 192.168.1.230: icmp_seq=3 ttl=63 time=9.77 ms

But now my last step is for internet, DNS isn't working properly, do I need to add a specific conf for that?

root@nexus2-bullseye-latest5:~# dig www.google.com

; <<>> DiG 9.16.22-Debian <<>> www.google.com
;; global options: +cmd
;; connection timed out; no servers could be reached

fmutshe

never mind, turned out I was missing resolvconf binary on the client so the /etc/openvpn/update-resolv-conf script wasn't working.

After installing resolvconf, DNS server is correctly pushed to the client and I can resolve names.

Thanks to everyone, we can close this now as it is solved.