Port forwarding from OpenVPN Client

[almaster76]

Hello, i've a small problem. I installed openvpn access server on a remote vps and configured to allow my asuswrt merlin to connect as a client. On the server, I have successfully opened a port for a web server that I have locally, inserting the right port forwarding configuration for the openvpn access server user. Tunnel between router and openvpn access server opens successfully. I also put the following rule in asuswrt merlin:

iptables -t nat -A PREROUTING -i tun11 -p tcp --dport 8080 -j DNAT --to-destination 192.168.1.20:8080

Unfortunately, however, port forwarding in the router seems to work only if I enable traffic redirection in the tunnel via VPN Director for the client in question (192.168.1.20). But I don't want to redirect all client traffic, I just want port forwarding through the tunnel. The problem is then only in the router configuration (via VPN Director it works). Does anyone have any idea how I can fix this issue? Thanks.

 

[ZebMcKayhan]

But I don't want to redirect all client traffic, I just want port forwarding through the tunnel.

So, how would you expect the server replies to find it's way back to the client over VPN if this is not the normal path? the client will not accept if the reply came through a different path. connection tracking is not involved in routing typically, but this could be made, using connmark and mark entire connections and routing based on marks. something like this: https://serverfault.com/questions/1107846/how-to-route-a-reply-packet-to-the-device-it-coming-from

but it needs to be modified for our routers, and for your use case. some inspiration here maybe https://www.snbforums.com/threads/e...to-vpn-policy-based-routing.71993/post-785284

it may be noted that the usage of fwmarks may cause conflicts with AI Protect so it may be a bad idea to use these together.

Best of luck!

 

[almaster76]

So, how would you expect the server replies to find it's way back to the client over VPN if this is not the normal path? the client will not accept if the reply came through a different path. connection tracking is not involved in routing typically, but this could be made, using connmark and mark entire connections and routing based on marks. something like this: https://serverfault.com/questions/1107846/how-to-route-a-reply-packet-to-the-device-it-coming-from

but it needs to be modified for our routers, and for your use case. some inspiration here maybe https://www.snbforums.com/threads/e...to-vpn-policy-based-routing.71993/post-785284

it may be noted that the usage of fwmarks may cause conflicts with AI Protect so it may be a bad idea to use these together.

Best of luck!

Thanks for your reply. In the meantime I accidentally found a solution that works but I can't figure out why. In addition to configuring via iptables, I modified the rule in VPN Director that redirects specific host traffic through the tunnel by adding, in the "Remote IP" field, the subnet created by OpenVPN (192.168.155.0/24). This is because I thought that the problem was in the failed routing between the local subnet and the subnet created for the vpn, but I didn't find documentation for the "Remote IP" field of VPN Director. With this configuration, however, the device goes on the internet through the router's WAN (get router's public IP) and at the same time responds correctly on the ports open in the tunnel!! But I want to better understand why!
Can anyone advise where to find documentation on this VPN Director "Remote IP" field? Thanks.

 

[ZebMcKayhan]

but I didn't find documentation for the "Remote IP" field of VPN Director.

the difference is just if the rule shall be applied based on source address (which usually is a local ip) or a destination address (which could be either local or remote). if you i.e. put in 8.8.8.8 in remote ip, it means all dns lookups to this dns will be sent over VPN regardless of which local ip requests the lookup. access to your VPS should be handled like this so all local resources have routes to the VPS via the policy route table.

But I want to better understand why!

The reason is that you VPS seems to masquarade packets that are forwarded. this is the same function that your router does on your lan to wan traffic to get all clients to use a single wan ip. so, this means all forwarded requests to your web server looks like they are from the VPS itself. it solves the issue with reverse path routing.

It's is not the solution I would recommend, as you completely loose all ability to see which internet ip that is accessing your web server. but it's up to you.

 

[almaster76]

the difference is just if the rule shall be applied based on source address (which usually is a local ip) or a destination address (which could be either local or remote). if you i.e. put in 8.8.8.8 in remote ip, it means all dns lookups to this dns will be sent over VPN regardless of which local ip requests the lookup. access to your VPS should be handled like this so all local resources have routes to the VPS via the policy route table.


The reason is that you VPS seems to masquarade packets that are forwarded. this is the same function that your router does on your lan to wan traffic to get all clients to use a single wan ip. so, this means all forwarded requests to your web server looks like they are from the VPS itself. it solves the issue with reverse path routing.

It's is not the solution I would recommend, as you completely loose all ability to see which internet ip that is accessing your web server. but it's up to you.

Thanks again for the explanation. Finally I understand the meaning of the "Remote IP" field. As for the loss of the ability to see the internet address of those accessing the server, I don't care because the web server is only used for some tests and not for publishing real services.