OpenVPN Legacy Migration to OpenVPN Instance - Routing to client gw [SOLVED]

Started by cweakland, May 21, 2025, 03:19:03 PM

Previous topic - Next topic
May 21, 2025, 03:19:03 PM Last Edit: May 21, 2025, 06:52:12 PM by cweakland Reason: Solved!
I have a OpenVPN client that acts as gateways. I currently access a remote network behind the remote OpenVPN client. This works fine under the Legacy OpenVPN configuration. However, I have tried (and failed) to migrate this configuration to the new OpenVPN "instances". I can get the tunnel to form, and I can see traffic leaving in the logs and in a tcpdump, but the routed traffic (i.e. 192.168.1.0/24) never makes it to the remote end. If I put the client back on the legacy server config, it just works.

Example:

[LAN Client 10.7.7.16] <-> [OpnSense] (NAT all traffic to OpenVPN server side IP) <-> (ovpns1 -Server Side:10.7.7.201 - Client Side:10.7.7.202) - [Debian Real Client IP 192.168.1.164] - (Client Network 192.168.1.0/24)

Here is a tcpdump from my OpnSense Openvpn Server:

During the capture I pinged 192.168.1.1 (remote network) and 10.7.7.202 (OpenVPN TUN client IP). You can see the remote client side IP respond, but the packet to 192.168.1.1 never makes it to the remote side.

# tcpdump -nn -i ovpns1 icmp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ovpns1, link-type NULL (BSD loopback), snapshot length 262144 bytes
09:05:20.480107 IP 10.7.7.201 > 192.168.1.1: ICMP echo request, id 1, seq 3316, length 40
09:05:25.473947 IP 10.7.7.201 > 192.168.1.1: ICMP echo request, id 1, seq 3317, length 40
09:05:26.540133 IP 10.7.7.201 > 10.7.7.202: ICMP echo request, id 1, seq 3318, length 40
09:05:26.581940 IP 10.7.7.202 > 10.7.7.201: ICMP echo reply, id 1, seq 3318, length 40
09:05:27.549951 IP 10.7.7.201 > 10.7.7.202: ICMP echo request, id 1, seq 3319, length 40
09:05:27.601653 IP 10.7.7.202 > 10.7.7.201: ICMP echo reply, id 1, seq 3319, length 40
09:05:30.464978 IP 10.7.7.201 > 192.168.1.1: ICMP echo request, id 1, seq 3320, length 40
09:05:35.461030 IP 10.7.7.201 > 192.168.1.1: ICMP echo request, id 1, seq 3321, length 40
^C
8 packets captured
29 packets received by filter
0 packets dropped by kernel

$ sudo tcpdump -i tun0 icmp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on tun0, link-type RAW (Raw IP), snapshot length 262144 bytes
09:05:26.558456 IP 10.7.7.201 > 10.7.7.202: ICMP echo request, id 1, seq 3318, length 40
09:05:26.558500 IP 10.7.7.202 > 10.7.7.201: ICMP echo reply, id 1, seq 3318, length 40
09:05:27.573679 IP 10.7.7.201 > 10.7.7.202: ICMP echo request, id 1, seq 3319, length 40
09:05:27.573721 IP 10.7.7.202 > 10.7.7.201: ICMP echo reply, id 1, seq 3319, length 40
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel

On the firewall I see the packets being accepted on the internal interface vtnet0_vlan5, natted, and being sent out the ovpns1 interface

Relevant logs:

2025-05-21T09:04:56-04:00    Informational    filterlog    321,,,53e5b031704847c121cc75f16415bc29,ovpns1,match,pass,out,4,0x0,,127,6267,0,none,1,icmp,60,10.7.7.201,192.168.1.1,datalength=40   
2025-05-21T09:04:56-04:00    Informational    filterlog    5,,,0,ovpns1,match,nat,out,4,0x0,,127,6267,0,none,1,icmp,60,10.7.7.16,192.168.1.1,datalength=40   
2025-05-21T09:04:56-04:00    Informational    filterlog    225,,,48fd8e8cb60ac9658d99782f3473edbc,vtnet0_vlan5,match,pass,in,4,0x0,,128,6267,0,none,1,icmp,60


Can anyone point me in the right direction on how to make this work?

Thanks again!
Chris

Did you create a Client Specific Override for the client in question?
And if so, is it applied properly?

I just did, and it worked!!

I created a client specific override and placed the foreign network (In my case 192.168.1.0/24) in "Remote Network" field. 

I did not realize the difference between the OpenVPN server "Remote networks" and the "Remote networks" for the Client Specific Overrides. In the overrides the "remote networks"  are configured via iroute clauses in OpenVPN and inform the server to send these networks to this specific client.

Thank you!