Port Forwarding over OpenVPN Site to Site
-
I barely know much about routing and networking, so I need help here. I am trying the best I can, though.
I have the publicly connected WAN (pfA) and a double nat (pfB). pfA is hosting an OpenVPN Server for site to site, where pfB is the client. They both can contact their networks and both have assigned an interface to the VPN tunnel.
What I am trying to do is something like this:
Public WAN pfA (3389) (1.2.3.4) -> OpenVPN Interface -> Private LAN pfB -> RDP Server (3389) (192.168.10.123).
Right now I tried to just add the NAT Port Forwarding rule in pfA to the IP since it is pingable by the router, and both sides can ping each other, but the port forwarding just doesn't work. LAN to VPN-LAN works, but WAN to VPN-LAN doesn't.
Am I missing something here?
-
@tonny512
I don't recommend to access RDP via the internet at all. You should tunnel the whole path.However, to forward WAN traffic over the VPN in general consider following:
- If pfB is still on version 2.5.1 upgrade the box before you go on.
- On pfB you have to ensure that a firewall pass rule on the interface you have assigned to the OpenVPN client instance is matching the incoming traffic from pfA.
That means, there must no pass rule on the OpenVPN tab and as well no floating rule match the traffic.
Consider that both would have priority over the interface tab.
-
@viragomann RDP was just an example.
pfB was updated to 2.5.2 today.
OpenVPN interface has no rules.
The VPN is assigned to OPT2.
There is also no floating rules set.
-
@tonny512
Should work, doesn't it? -
@viragomann It doesn't. It could have something to do with the RDP protocol though. I could try a different software to test the port.
-
@tonny512
I assumed that pfB is the default gateway on the destination computer.On side A the NAT port forwarding to the destination IP and the firewall rule have to be set properly.
Also consider that the destination computer might block access from out of his own subnet. That is the default setting of Windows firewalls.
You can sniff the traffic using Diagnostic > Packet capture on pfB to see what's going on.
If Windows blocks the access you will see the packets on side B's LAN interface going to the computer, but no responses coming back. -
@viragomann I just tried it again with a different server-side and it worked flawlessly.