OpenVPN client lan to reach Server lan

Question

I have OpenVPN Server running in VPC and client running in office network.

Have following table on 10.24.11.37

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.24.11.0      0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0         10.24.11.1      0.0.0.0         UG    100    0        0 eth0

Want 10.24.11.37 to connect to 10.2.1.145, So I added following routes to 10.24.11.37.

route add -net 10.8.0.0 netmask 255.255.255.0 gw 10.24.11.235
route add -net 10.2.0.0 netmask 255.255.0.0 gw 10.24.11.235

Now I have following table on 10.24.11.37

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.8.0.0        10.24.11.235    255.255.255.0   UG    0      0        0 eth0
10.24.11.0      0.0.0.0         255.255.255.0   U     0      0        0 eth0
10.2.0.0        10.24.11.235    255.255.0.0     UG    0      0        0 eth0
0.0.0.0         10.24.11.1      0.0.0.0         UG    100    0        0 eth0

Now I am able to ping 10.8.0.2 from 10.24.11.37 But not able to ping 10.2.1.145, 10.8.0.1, 10.2.2.101 from 10.24.11.37

I have following routes on 10.24.11.235

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.8.0.1        128.0.0.0       UG    0      0        0 tun0
0.0.0.0         10.24.11.1      0.0.0.0         UG    202    0        0 eth0
10.8.0.0        0.0.0.0         255.255.255.0   U     0      0        0 tun0
10.24.11.0      0.0.0.0         255.255.255.0   U     202    0        0 eth0
38.xxx.xxx.291  10.24.11.1      255.255.255.255 UGH   0      0        0 eth0
128.0.0.0       10.8.0.1        128.0.0.0       UG    0      0        0 tun0

From OpenVPN Server 10.2.2.101 I can ping 10.8.0.2, but not 10.24.11.235. I tried to add sudo ip route add 10.24.11.0/24 via 10.8.0.2 dev tun0 to OpenVPN Server 10.2.2.101. But it didn't fix the issue.

I have disabled Source/Destination Check for OpenVPN Server (EC2 Instance), enabled IP forwarding (net.ipv4.ip_forward = 1) on OpenVPN Server 10.2.2.101 & OpenVPN Client 10.24.11.235

And on OpenVPN Server 10.2.2.101

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.2.2.1        0.0.0.0         UG    100    0        0 ens5
10.2.2.0        0.0.0.0         255.255.255.0   U     0      0        0 ens5
10.2.2.1        0.0.0.0         255.255.255.255 UH    100    0        0 ens5
10.8.0.0        0.0.0.0         255.255.255.0   U     0      0        0 tun0
10.24.11.0      10.8.0.2        255.255.255.0   UG    0      0        0 tun0

OpenVPN Server 10.2.2.101 & OpenVPN Client 10.24.11.235 has following firewall rules

$ sudo iptables -nvL FORWARD
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

ping 10.8.0.2 from 10.24.11.37 doesn't show up in sudo tcpdump -i tun0 icmp on 10.24.11.235 but shows up in sudo tcpdump -i eth0 icmp on 10.24.11.235

sudo iptables -S on 10.24.11.235

-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A FORWARD -s 10.24.11.0/24 -d 10.2.0.0/16 -j ACCEPT
-A FORWARD -s 10.2.0.0/16 -d 10.24.11.0/24 -j ACCEPT
-A FORWARD -s 10.24.11.0/24 -d 10.8.0.0/24 -j ACCEPT
-A FORWARD -s 10.8.0.0/24 -d 10.24.11.0/24 -j ACCEPT
-A FORWARD -s 10.24.11.0/24 -d 10.2.0.0/16 -j ACCEPT
-A FORWARD -s 10.2.0.0/16 -d 10.24.11.0/24 -j ACCEPT

sudo iptables -S on 10.2.2.101

-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A FORWARD -s 10.24.11.0/24 -d 10.2.0.0/16 -j ACCEPT
-A FORWARD -s 10.2.0.0/16 -d 10.24.11.0/24 -j ACCEPT
-A FORWARD -s 10.2.0.0/16 -d 10.8.0.0/24 -j ACCEPT
-A FORWARD -s 10.8.0.0/24 -d 10.2.0.0/16 -j ACCEPT
-A FORWARD -s 10.24.11.0/24 -d 10.2.0.0/16 -j ACCEPT
-A FORWARD -s 10.2.0.0/16 -d 10.24.11.0/24 -j ACCEPT

What route I am missing here ?

Update :

When I ping 10.8.0.2 from 10.2.1.145 I see ICMP echo request/reply on 10.2.2.101 with sudo tcpdump -i tun0 -nn icmp.

But when I ping 10.24.11.235 from 10.2.1.145 I see following

$ ping -c 1 10.24.11.235
PING 10.24.11.235 (10.24.11.235) 56(84) bytes of data.
From 10.2.2.101: icmp_seq=1 Redirect Host(New nexthop: 10.2.2.1)
From 10.2.2.101: icmp_seq=1 Redirect Host(New nexthop: 10.2.2.1)
From 10.2.2.101: icmp_seq=1 Redirect Host(New nexthop: 10.2.2.1)
From 10.2.2.101: icmp_seq=1 Redirect Host(New nexthop: 10.2.2.1)
From 10.2.2.101: icmp_seq=1 Redirect Host(New nexthop: 10.2.2.1)
From 10.2.2.101: icmp_seq=1 Redirect Host(New nexthop: 10.2.2.1)
From 10.2.2.101: icmp_seq=1 Redirect Host(New nexthop: 10.2.2.1)
From 10.2.2.101: icmp_seq=1 Redirect Host(New nexthop: 10.2.2.1)

--- 10.24.11.235 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

On 10.2.2.101 with sudo tcpdump -i ens5 -nn icmp :

$ sudo tcpdump -i ens5 -nn icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens5, link-type EN10MB (Ethernet), capture size 262144 bytes
13:36:45.072517 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.072544 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.072568 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.072575 IP 10.2.2.101 > 10.2.2.46: ICMP redirect 10.24.11.235 to host 10.2.2.1, length 92
13:36:45.072576 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.072602 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.072606 IP 10.2.2.101 > 10.2.2.46: ICMP redirect 10.24.11.235 to host 10.2.2.1, length 92
13:36:45.072700 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.072726 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.072782 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.072803 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.072822 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.072848 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.072894 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.072915 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.072980 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.072983 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073020 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073046 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073087 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073090 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073128 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073145 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073168 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073170 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073194 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073233 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073292 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073341 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073391 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073411 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073432 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073435 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073452 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073475 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073498 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073520 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073540 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073543 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073559 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073584 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073588 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073605 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073609 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073625 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073645 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073665 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073669 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073686 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073704 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073729 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073732 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073749 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073753 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073772 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073792 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073810 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073834 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073837 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073854 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073857 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073892 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073895 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073911 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073934 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073938 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64
13:36:45.073956 IP 10.2.2.46 > 10.24.11.235: ICMP echo request, id 29545, seq 1, length 64

Update : Dec 18, 2019

I added route 10.24.11.0 255.255.255.0 to /etc/openvpn/server.conf, and restarted openvpn@server. No other config changes. Still can't ping

When I ping 10.8.0.2 from 10.2.1.145 I see following on 10.2.2.101 with sudo tcpdump -i tun0 -nn icmp/ sudo tcpdump -i ens5 -nn icmp

17:09:53.076642 IP 10.2.7.61 > 10.8.0.2: ICMP echo request, id 27504, seq 1, length 64
17:09:53.158914 IP 10.8.0.2 > 10.2.7.61: ICMP echo reply, id 27504, seq 1, length 64
17:09:54.077827 IP 10.2.7.61 > 10.8.0.2: ICMP echo request, id 27504, seq 2, length 64
17:09:54.160234 IP 10.8.0.2 > 10.2.7.61: ICMP echo reply, id 27504, seq 2, length 64

When I ping 10.2.1.145 from 10.24.11.37 I get following on 10.2.2.101 with sudo tcpdump -i tun0 -nn icmp

17:17:01.361549 IP 10.24.11.37 > 10.2.1.145: ICMP echo request, id 24639, seq 0, length 64
17:18:14.451241 IP 10.24.11.37 > 10.2.1.145: ICMP echo request, id 8768, seq 0, length 64

ofirule · Answer 1 · 2019-11-19T17:37:41.803

I haven't tested it but this is the general idea for the solution:

On 10.24.11.37:

# Add routes
route add -net 10.8.0.0 netmask 255.255.255.0 gw 10.24.11.235 # this is not mandatory, only if you want 10.24.11.37 to be able to connect to 10.8.0.0/24
route add -net 10.2.0.0 netmask 255.255.0.0 gw 10.24.11.235

On 10.24.11.235:

# Add route
route add -net 10.2.0.0 netmask 255.255.0.0 gw 10.8.0.1

# Allow forwarding rules

## this is not mandatory, only if you want 10.24.11.37 to be able to connect to 10.8.0.0/24
iptables -A FORWARD -s 10.24.11.0/24 -d 10.8.0.0/24 -j ACCEPT
iptables -A FORWARD -s 10.8.0.0/24 -d 10.24.11.0/24 -j ACCEPT

## For access to and from 10.2.1.145 / 10.24.11.37
iptables -A FORWARD -s 10.24.11.0/24 -d 10.2.0.0/16 -j ACCEPT
iptables -A FORWARD -s 10.2.0.0/16 -d 10.24.11.0/24 -j ACCEPT

On 10.2.2.101:

# Add route
route add -net 10.24.11.0 netmask 255.255.255.0 gw 10.8.0.2

# Allow forwarding rules

## this is not mandatory, only if you want 10.2.1.145 to be able to connect to 10.8.0.0/24
iptables -A FORWARD -s 10.2.0.0/16 -d 10.8.0.0/24 -j ACCEPT
iptables -A FORWARD -s 10.8.0.0/24 -d 10.2.0.0/16 -j ACCEPT

## For access to and from 10.2.1.145 / 10.24.11.37
iptables -A FORWARD -s 10.24.11.0/24 -d 10.2.0.0/16 -j ACCEPT
iptables -A FORWARD -s 10.2.0.0/16 -d 10.24.11.0/24 -j ACCEPT

On 10.2.1.145:

# Add routes
route add -net 10.8.0.0 netmask 255.255.255.0 gw 10.2.2.101 # this is not mandatory, only if you want 10.2.1.145 to be able to connect to 10.8.0.0/24
route add -net 10.24.11.0 netmask 255.255.255.0 gw 10.2.2.101

Basically you need to add routes and allow relevant forwarding on all hosts

score 1 · Answer 2 · answered Nov 25 '19 at 01:34

let me make one guess what is causing your issue and point you how to (hopefully) solve it...

I think your problem is "internal routing" on openvpn server. Once you open the openvpn session to the server, there is created "internal routing record" saying that 10.8.0.2 is reachable via currently established session. Next to it, there is "general" OS system's routing record says 10.8.0.0/24 should be rechable via tun0 - openvpn. These two information together provide all necessary information how to reach the 10.8.0.2.

Even you have allowed forwarding traffic for 10.24.11.0/24 on the system and point the traffic to the tun0 (openvpn server session) once it reach the openvpn "internal routing" there is no information how to deal further...

To have this solved you need to utilize CCD (Client Config Dir) option on openvpn server and create custom config for the client corresponding with 10.8.0.2. There you can add "iroute 10.24.11.0 255.255.255.0" record which will cause setting internal routing rule with session establishing... In other words once client will be connected, there will be "normally" created internal routing record for 10.8.0.2 (this is working even now) and next to it it will set also internal routing rule for 10.24.11.0/24 to be directed via this session to 10.8.0.2. This have to be set up using ccd as in theory 10.8.0.2 not have to be static so the openvpn server have to know which session is correct to use for traffic routing... More information on this topic you can find e.g. in openvpn howto page.

In case you want to have "OS system's routing record" persistent you should add "route 10.24.11.0 255.255.255.0" to the openvpn config on server side - with starting openvpn server it will set up this system rule.

Hopefully this will help you. Good Luck !

OpenVPN client lan to reach Server lan

2 Answers2