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

Did you check if forwarding is enabled? `cat /proc/sys/net/ipv4/ip_forward` — Piotr P. Karwasz, Nov 15 '19 at 18:02
take a look at this for AWS side - https://dev.to/setevoy/openvpn-openvpn-access-server-set-up-and-aws-vpc-peering-configuration-5fpg — Jacob Evans, Nov 15 '19 at 18:04
Next check if you don't have any firewall drop rules on the servers: `iptables -nvL FORWARD` — Piotr P. Karwasz, Nov 15 '19 at 18:12
On `10.2.2.101` you use `10.8.0.1` as gateway, should be `10.8.0.2` — Piotr P. Karwasz, Nov 15 '19 at 20:24
1) Post OpenVPN server version and operating system version of server; 2) Check your VPC configuration to ensure there are layer 3 pathways there (i.e. route table, ACL, security group(s)). Sounds like you're missing something on the VPC end, probably in one of your route tables pointing to your ipsec tunnel (vpc peering connection) — lobi, Nov 20 '19 at 17:04

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

1

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

edited Nov 19 '19 at 17:37

answered Nov 19 '19 at 17:31

ofirule

143
7

I added all routes & forwards. Still not able to ping `10.2.1.145` from `10.24.11.37`. But when I start ping `10.2.1.145` from `10.24.11.37`, I see `ICMP echo request/reply` on `10.2.2.101` with `tcpdump -i ens5 -nn icmp` but not with `tcpdump -i tun0 -nn icmp`. Also see `ICMP echo request` on `10.24.11.235` but no reply. – roy Nov 19 '19 at 19:51
When I ping `10.24.11.37` from `10.2.1.145`, `ICMP echo request` appears on `10.2.2.101` with `tcpdump -i tun0 -nn icmp`. But no `ICMP echo request` on `10.24.11.235` with `tcpdump -i tun0 -nn icmp` or `tcpdump -i eth0 -nn icmp` – roy Nov 19 '19 at 19:57
Usually AWS instances don't respond to ping. I would try: 1) listening on port with netcat in 10.2.1.145 and try to connect to it. 2) trying to ping from 10.2.1.145 to 10.24.11.37 3) running traceroute from both ends – ofirule Nov 20 '19 at 00:22
Have this `route add -net 10.24.11.0 netmask 255.255.255.0 gw 10.8.0.2` on `10.2.2.101` – roy Nov 20 '19 at 15:46
With netcat I can connect from `10.24.11.37` to `10.24.11.235` but not `10.2.2.101` & `10.2.1.145`. Can connect from `10.24.11.235` to `10.2.2.101` & `10.2.1.145`, Can connect from `10.2.1.145` to `10.2.2.101` & `10.8.0.2` but not to `10.24.11.235` or `10.24.11.37`, Can connect from `10.2.2.101` to `10.8.0.2` but not to `10.24.11.235` or `10.24.11.37`. – roy Nov 20 '19 at 15:48
Missing netcat from `10.24.11.37` to `10.8.0.1`. Do you have any iptables filter rules on one of the instances?. It's weird that netcat from `10.2.2.101` to `10.8.0.2` works but not to `10.24.11.235` since it's the same machine. – ofirule Nov 20 '19 at 16:32
netcat from `10.24.11.37` to `10.8.0.1` doesn't work. I see all `FORWARD ACCEPT` rules for `iptables -S` on all hosts, no `DROP` rule on any host. – roy Nov 20 '19 at 16:55

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

1

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 !

answered Nov 25 '19 at 01:34

Kamil J

1,587
1
4
10

I created `/etc/openvpn/ccd/client1` with `iroute 10.24.11.0 255.255.255.0` on OpenVPN Server then restarted OpenVPN Server & Client processes. But I was not able to reach `10.2.0.0/16` from `10.24.11.37` & vice versa. – roy Nov 25 '19 at 20:09
On OpenVPN server `10.2.2.101` I see this `Mon Nov 25 15:27:31 2019 client1/189.132.158.78:27098 MULTI: Learn: 10.24.11.37 -> client1/163.132.158.78:27098` – roy Nov 25 '19 at 20:34
Now it should be ok on openVPN side. Please check routing stuff (e.g. if 10.2.x.y has setup route for 10.24.11.x/24 pointing to openvpn server - you can receive ICMP request but ICMP reply could be routed to default route which not necessary have to be openVPN server ;-) ) and also firewall stuff that is it accepted / passed and proceed. With this "Learn" stuff the openvpn part of the issue should be solved as client seems to be routing properly and server accept this IP range (otherwise you don't see this this "Learn" log). – Kamil J Nov 26 '19 at 10:21
I have added some details about ping in the main question. I have route for `10.24.11.x/24` set into AWS Route table pointing to OpenVPN Server interface. – roy Dec 03 '19 at 21:24
Based on updated ping stuff it seems that there is routing setting issue on openVPN server. As you can see "redirect" and destination IP, it seems like kernel is not passing it to openVPN instance but redirecting to default route (I guess 10.2.2.1 is default GW). Try not to add system route via `ip route add 10.24.11.0/24...` but add it to "basic" openvpn server config like `route 10.24.11.0 255.255.255.0` (note "missing" push). This would be processed during start and pass to system routing records ("push" staff is passed to clients). I think there would be "generic" destinationo for openvpn. – Kamil J Dec 04 '19 at 23:46
I have added ping response after adding the route. – roy Dec 18 '19 at 22:19

OpenVPN client lan to reach Server lan

2 Answers2