OpenVPN Support Forum

Hello guys,

I have the following constellation:
LOCAL-CLIENT <---> VPN-SERVER <---> VPN-CLIENT <---> TARGET

I want to reach "TARGET" from "LOCAL-CLIENT".
What I did:
a) on "LOCAL-CLIENT": I added a route "route add TARGET_IP MASK 255.255.255.255 VPN_CLIENT_IP
b) activated "IPEnableRouter" on VPN_CLIENT

I would assume now the following hops are done when I ping "TARGET" from "LOCAL_CLIENT".
LOCAL_CLIENT > VPN-SERVER > VPN_CLIENT > TARGET

Unfortunately it doesn't work.
For trial I just added a port-forwarding on "VPN_CLIENT" TO "TARGET" for a specific service.
That works just fine. So I think something does not work with the IP-routing via TAP-Device.

IP-Routing itself is working on "VPN-CLIENT" as I tested it with to local IP-interfaces without a problem.

What am I missing which prevents the TAP-Interface on my vpn-client to forward to target-ip ?

THANKS in advance
mts


REMARK: VPN-Client is a windows-machine

Hello,

I would probably instead have a normal route on the client side pushed from the server side using OpenVPN like;
push "route TARGET_IP 255.255.255.255"

That makes the VPN client sends the data for TARGET_IP to the VPN server, which then has to figure out the rest. This also centralizes the configuration and responsibility of route management as much as possible on the server side, so any changes don't require fiddling with the VPN client config too much. On the VPN server you can have a routing table addition that sends TARGET_IP to the second VPN client where the TARGET_IP can be reached. And on that second VPN client have IP forwarding enabled so it can take the packet from the tunnel interface and pass it to the local network where TARGET_IP lives.

Most likely the packet will then arrive there at the TARGET_IP. I think in your described configuration it would also most likely make it there.

However it is probably not able to respond without further configuration, because TARGET_IP is getting a packet from the first VPN client's IP address and TARGET_IP has probably no idea how to respond to that. On the TARGET_IP system you then need to set up a return route to the second VPN client's local network IP address, so it can then forward the return traffic to the VPN server and it can then send it further to the first VPN client. Alternatively you can do it as a static route in the network where TARGET_IP works so it would hit the default gateway and get redirected to the VPN server's IP address in the local network. That has the advantage that if you cannot add a route on target IP device, or if there are multiple target IP devices, you can do it in the router once and it just works for all.

To describe those 2 options;

Add a route on the target IP system:
1st VPN client > VPN server > 2nd VPN client > target IP > 2nd VPN client > VPN server > 1st VPN client

Add a static route on the network where target IP lives:
1st VPN client > VPN server > 2nd VPN client > target IP > default gateway > 2nd VPN client > VPN server > 1st VPN client

And as always, use tcpdump or wireshark to just filter for ICMP echo-request and echo-reply packets while doing a ping, to see where the packets go, if their source and destination IP addresses look sane, and where it stops being forwarded.

My guess is the packets are in your current situation already reaching the target IP system but it can't respond back so the responses go to default gateway and then just get lost.

Kind regards,
Johan