Port Forward to remote OpenVPN host
-
I'm trying to port forward to a host on a remote OpenVPN site-to-site connection.
WANIP:8815 -> PfSenseA (172.27.30.1) -> S2S OpenVPN (/30 tunnel) -> PfSenseB (192.168.0.254) -> host (192.168.0.3)
The site-to-site VPN has been working perfectly for years.
I've setup plenty of PfSense port forwards but never to a remote subnet.
I've read several posts stating that this should be possible providing I ensure that PfSenseB has an interface assigned for the OpenVPN server with rules to pass traffic, and that the PfSenseB OpenVPN interface group has no matching rules, so that reply-to can get added, e.g https://forum.netgate.com/topic/130335/port-forwarding-into-remote-vpn-network
Unlike the post above, I have no bridges in my setup.
I have tried setting the destination IP on the PfSenseA port forward to 192.168.0.3 (along with the port of course). Is that the right way to do this? Or maybeI need a VIP to make this work?
I don't think I need to configure Outbound NAT on PfSenseA in this scenario given that it should just be following the reply path.
I have a firewall rule on the PfSenseA LAN that policy-routes all RFC1918 traffic via the OpenVPN gateway.
I can't get this to work. The request just times out. Any pointers much appreciated.
-
From the top of my head:
- On pfSense A forward port 8815 directly to the ip of the final host (192.168.0.3) (this should create the firewall rule automagically)
- On pfSense A set a routing entry that forwards anything to 192.168.0.3/32 via pfSenseB (192.168.0.254) if that doesn't exist already via some other route like e.g. 192168.0.0/24
- On pfSense B set a firewall rule that allows the forwarded traffic in from the tunnel to the host
Now the way back ...
- On the host set the default gateway to pfSense B
- On pfSense B set a rule that forwards everything from host, source port 8815 via tunnel to pfSenseA. You can also just forward everything from host to pfSenseA but I doubt you want all the traffic going over said tunnel.
Check if the connection from the outside works...
You can just run tcpdumps on all the involved interfaces and check how the package traverses along the path and see how the answer then goes backwards. If you do that, you can find all problems along the way and fix them.
Most people forget to configure the way back especially when multiple default gateways are involved. It is important that all the answers to connection requests on port 8815 at host are returned through the tunnel via pfSense A.
There are other scenarios where you can just let the host answer via the default gateway on pfSense B and source NAT the host's IP-Address to the one of pfSense A that the original request went to, but that's something that is NOT working on dialup accounts. It's usually more a scenario for bigger data centers.
Cu
-
I got this working. The issue was indeed the path back from the host to the requester.
To fix it I added an Outbound NAT hybrid rule on PfSenseA, setting the 'Interface' field as the assigned OpenVPN interface, and the 'Address' field set to 'Interface Address'.
I then had to add my VPN tunnel subnet to the source alias on the OpenVPN Pass rule on PfSenseB, since the port-forwarded traffic would now show as coming from the tunnel subnet.
By doing it this way I did not have to change the default gateway on the host.
-
Doing that you lose the source address of the connection at the host being connected to.
It sounds like you misunderstood something. A possibly better option would be:
- Assign an interface to the OpenVPN instance on pfSenseB
- Make sure the connections into pfSenseB do not match any rules on the OpenVPN tab
- Make sure they only match rules on the assigned interface tab.
reply-to will now take care of making sure reply traffic goes back out the OpenVPN tunnel it came in on.
You do not need an assigned interface on the node receiving the connections from the internet, pfSenseA, to make this work.
-
@Derelict said in Port Forward to remote OpenVPN host:
Doing that you lose the source address of the connection at the host being connected to.
Hi Derelict
Thanks for chiming in.
That's actually what I had tried first. That's what I thought would work, based on what you wrote the other post I linked to in my original post.
But I did all that - that's what I tried to describe in my original post - assigned interface, ensured no matching rule on OpenVPN tab, and matched a rule on the assigned interface tab. All of this is on PfSenseB. But no joy.
I actually engaged a network engineer who took about 5 minutes on a screenshare session to look at tcpdumps and see the issue. We put the Outbound NAT rule in place as described and bingo everything started working. How is that possible if, as you say, the host has lost the source public IP? I saw the app working over this config with my own eyes.
One detail that may be relevant: in my setup PfSenseB is the VPN server and PfSenseA is one of 4 site to site clients. I know that doesn't make a lot of sense architecturally (i.e. why wouldn't you just port forward to the server) but I am doing it as a proof of concept prior to changing my architecture (VPN server will become client to a new VPN server that will have the port forward). I mention this because I wonder if reply-to is affected by this since the assigned interface represents the end-point of 4 VPN tunnels so maybe it wouldn't know which of the 4 to send the reply to? I'm completely self-taught on pfsense and routing does my head in so this is pure speculation!
I'd be happy to post config screenshots etc. While it is working now, I prefer it when things make sense and the simplicity of reply-to handling the return connection is appealing.
-
Right. But it works every time. You did something incorrectly.
Anyway, glad you have it working with NAT.
About all that could make it not work is the target host's default gateway not being back to pfSense. In that case you have to NAT so the replies are same-subnet. Reply-to only helps if pfSense actually sees the reply traffic.
-
@Derelict said in Port Forward to remote OpenVPN host:
Right. But it works every time. You did something incorrectly.
Well it's possible but I don't think so. My best guess remains that the issue is with PfSenseB being a multi-client SSL/TLS VPN server as hypothesized in my last post.
Since my last post I have re-architected my VPN so that now PfSenseA (hosting the port forward) is the OpenVPN server, and PfSenseB (whose LAN has the target host on its subnet) is the OpenVPN client. And voila, the reply-to now works and hence Outbound NAT is no longer required.
About all that could make it not work is the target host's default gateway not being back to pfSense. In that case you have to NAT so the replies are same-subnet. Reply-to only helps if pfSense actually sees the reply traffic.
No, PfSenseB has always been the default gateway for this server.
Anyway, it's all working as expected now and I'm happy.
-
Final post for completeness:
In my last update I reported that reply-to was working without the Outbound NAT rule. And I swear that it was when first tested.
However when I did further testing a few hours later the connection through the port forward would not complete and I had to add the PfSenseA Outbound NAT rule back in as described earlier. Don't ask me - if I had the time and skills to figure this out I would. Instead I'm just questioning my sanity.
I do realise my credibility is now in tatters. Oh well. At least my port forward is working.
-
You only need an outbound NAT rule if reply-to is not working.
That is because all connections to the server will appear to the target server to be originating from the pfSense A OpenVPN tunnel address, which pfSense B has a specific route back to.