Using a VPS as an OpenVPN "jump server" to access LAN behind pfSense

Hi all,

Since this is my first post, I’d like to start by thanking @LTS_Tom for all the educational material he has created and for his tireless work to increase our awareness about security.

Thanks to him I decided to take the leap and start using pfSense on my home network and incorporate many best practices he explains in his videos.

Keeping security in mind, I was thinking what would be the “safest” way to access my home network remotely.

So that’s what I have in mind:

OpenVPN_pfSense

Instead of opening a port on pfSense to get access to the LAN via OpenVPN I thought it would be safer to use an external VPS (e.g. Linode, Vultr, etc) as an OpenVPN server (“jump server”) and setup the pfSense as a client.

Remote clients would then connect to the VPS to gain access to my home LAN behind pfSense (e.g. Linux VM’s via ssh, Windows shares, etc).

Another benefit besides keeping all ports closed on pfSense is that the home network WAN IP address is dynamic therefore accessing the VPS with a fix IP could potentially simplify the setup of the remote clients.

I would appreciate your thoughts on this setup and whether it would improve security somehow compared to setting up the OpenVPN server directly on pfSense.

If it makes sense, could you point me to resources on how to implement it?

I’ve googled around but could only find examples of LAN-LAN or remote clients to LAN. I tried to put both together but couldn’t get my head around the possible static routes that the server would need to push to the clients to allow the communication between both ends.

1 Like

Take a gander at crosstalksolutions youtube post setting up a Streisand VPN proxy server, think that would fit what you are looking to accomplish.

2 Likes

Thank you for the suggestion. I heard about Streisand, but I had the impression that it was a set of scripts to install different types of VPN access to a server, so your remote clients are not restricted to only OpenVPN.

I had a quick scan through the post at CrossTalkSolutions and it seems the setup he is explaining is remote client -> server. The key information that seems to be missing for me is how to allow communication between 2 clients that are connected to the server. In my specific case the remote client and my home LAN.

Maybe @LTS_Tom has an use case for this and would be interested in making a video?

I’ve been trying to get this going for myself with an almost identical use case. For about a month I’ve been hampered in that we just moved and I haven’t set up my home lab yet (waiting for power to be set up for the server. And for time to do it all).

The race is on which one of us will get it first! Lol @LTS_Tom, @beagle, or me :nerd_face:

FWIW, I’m planning basically the same topology except I’m going to try and put a couple more VPSes into the mix with Linode private IPs.

I ended up deciding to put my Zabbix server on a Linode instead of my lab where my WikiMedia server lives. I’m thinking I’m also going to plunk InvoiceNinja on my lab also, but will likely switch things around after a while - just for the punishment. Lol

1 Like

could just use ZeroTier if your trying to get to one device. ZeroTier also supports exposing the whole lan with a few clicks.

I’m not sure about @beagle, but my goal is to create my own intranet with monitoring, billing, VoIP, storage, documentation, remote connection (ScreenConnect) and possibly my own FOSS PSA tool. All that can be accessed securely from anywhere as if I was on the same LAN.

That’s my goal at least.

And, if it matters to anyone I’m planning to get around the dynamic IP I get from my ISP by basically creating my own dynamic DNS with the Linode Management API. Most of the info I find about dynamically changing the DNS entries in the Linode DNS management area are outdated and only use the old manager.linode.com interface. I have been digging around in the Linode API docs and see that it is possible to remotely update the A record with an API call from my lab server.

All of this is motivated by (1) I’m cheap and (2) to see if it can be done easily. I’ll have to collect my thoughts into a more coherent post with a topology map, I am a bit scattered right now in my explanation I guess.

BTW: would anyone else be interested in the process and result? I could do a write up on it after I get it going.

For dynds I just use Cloudflare as mentioned in this post:

1 Like

Did you ever get this setup? I’m trying to do the same thing and having issues. I have OpenVPN installed, but the VPN Server (public VPS) isn’t able to reach back into the VPN Client’s LAN network.

Always interested in solution!

That might have to do with firewall rules on the client machine.

In my understanding, this is how it should work:

  • Set up a VPN server on the VPS.
  • Connect the pfSense machine and the remote workstation to the VPN server as clients. You should have a network like 10.0.8.0/24 with three nodes. Let’s say the VPN server is 10.0.8.1, the pfSense machine is 10.0.8.2 and the remote workstation is 10.0.8.3. Suppose the private network at the pfSense machine you want to reach is 192.168.0.0/24.
  • Now you have to decide whether you want to enable the client-to-client option in the OpenVPN server. You can still achieve client to client communication even with this option disabled (cf. this ServerFault post) and this is what I would do because it allows for more fine grain traffic control on the server machine. This is also assumed for the rest of this post.
  • On the remote workstation, you need a route 192.168.0.0/24 via 10.0.8.2.
  • On the VPN server, you need a firewall rule to allow traffic coming in on the VPN interface destined for 192.168.0.0/24. Forwarding may have to be enabled in the kernel.
  • On the pfSense machine, you need a firewall rule on the VPN interface to allow traffic coming in on that interface destined for 192.168.0.0/24.

In conclusion:
When you create a packet destined for, say, 192.168.0.4 on the remote workstation, that machine will look in its routing table and see that the packet has to be sent to the machine with the IP address of 10.0.8.1, which is on the virtual interface created by OpenVPN. Internally, OpenVPN will send that packet through the tunnel to the VPN server, the packets travels up and down the network stack there and gets forwarded to 10.0.8.2. There, it is finally forwarded into the the target network.