set up pfSense as additional gateway into VPNs

viragomann

@sgw said in set up pfSense as additional gateway into VPNs:

googled for router on a stick with pfSense, found mostly setups using 2 VLANs on one NIC.

You have two network segments on two interfaces as well in fact. With at least two, a router makes sense. But only one of them has an outside NIC.
This one you connect the existing LAN subnet and the other one is the VPN subnet, which has a virtual interface inside pfSense.
On the VPN you have a route to the remote site. On the LAN you have the default route.

As mentioned, you can use either interface for this, but if it's the WAN, ensure the remove the "block private networks" check in the interface and in both cases enter the gateway directly there. This sets the default route automatically and add outbound NAT rules, so that pfSense is able to search for updates.

sgw

@viragomann I delayed the work on this because of other things. I might try to set that up next week or so and maybe get back here with additional questions.

As far as I understand I will setup one NIC with a LAN ip, plus adding a gateway (their existing router to internet) which basically turns my box into a pfSense with one WAN interface only, right?

Then I add my ovpn-client and proceed from there ... somehow ;-)

viragomann

@sgw said in set up pfSense as additional gateway into VPNs:

As far as I understand I will setup one NIC with a LAN ip, plus adding a gateway (their existing router to internet)

Best practice would be to pull the LAN IP from a DHCP server. So it gets the IP and gateway automatically.
This way you can set up your device in your network with the OpenVPN client to connect to your public IP and then move it into the other network and it should connect automatically.
This requires a DHCP server at the other location, of course.

As I remember, your intention is to get access to the remote sites LAN. So the devices LAN IP can be dynamic, but you have to nat all outgoing traffic.
So you should enable the hybrid mode in the outbound NAT and add a rule for any source IP. Then this rule is also applied to traffic from your site and the remote devices will only see the LAN address of pfSense talking to them.

sgw

@viragomann great help, thanks!
The idea with DHCP on LAN is cool, that was one of my question marks ..

The NAT-part: I will have to re-write for the whole LAN, as I dont know which PCs/IPs have to access my server behind the OpenVPN-tunnel.

I assume that won't be hard. I will set up a test-box asap and try that.

thanks for the helpful infos!

viragomann

@sgw
The outbound NAT rule can masquerade simply any:
interface: LAN
source: any
destination: any
translation: LAN address

So you don't have to care about your source subnet and the destination has to any anyway (at least for the firewall itself).

This is only a NAT rule. You can control the traffic with firewall rules in addition.

sgw

@viragomann

starting to set up my test box.

Disabled WAN and OPT1, LAN to dhcp (it gets 172.32.99.110 right now, I add this to explain my tests below).

Hybrid NAT was already in place, looks like suggested to me?

192.168.1.0/24 is the LAN on the server site, on the other side of the openvpn tunnel (which is already up and running)

I added a route on my local laptop:

ip r add 192.168.1.0/24 via 172.32.99.110

and in consequence I can ping an IP at the server site. Great.

I assume I can access the pfSense-WebGUI on its OpenVPN-tunnel IP. I have set up according firewall rules already for my first setup ... (allowing only specific IPs/LANs etc).

Looks very promising already, thanks!

viragomann

@sgw said in set up pfSense as additional gateway into VPNs:

Disabled WAN and OPT1

If WAN is disabled I don't expect to be able to add an outbound NAT rule to it.
So this seems confusing to me.

The static port 500 rule is only needed for IPSeec. I don't assume, that you intend to run an IPSec over this device.

And the OpenVPN rule seems pretty useless. The OpenVPN is the virtual interface facing to you (to the server). So why traffic going out on this interface should be translated to the LAN address?
Moreover as I got your goal in this, there shouldn't go any traffic to the server. Or do you want to allow access from the remote site?

Again, if your only one aim is to reach the remote sites LAN devices AND LAN is the only one enabled interface, all you need is a single outbound NAT rule:
interface: LAN
source: any
destination: any
translation: LAN address

This ensures that traffic from the server site to the remote LAN is translated to the remotes LAN IP and that pfSense can access the internet (as well the OpenVPN client).

Ensure that you have a proper firewall rule on the OpenVPN to allow access to the LAN subnet and to pfsense itself.

sgw

@viragomann

That IPSEC: seems to come from the IPSEC-Wizard or something. Sure, can be removed/uninstalled.

The openvpn-rule: might come from an earlier stage of this setup (I took a pre-configured box of "gen 1" and just modified it. Might be better to reset and start from scratch, yes).

One feature I haven't mentioned yet:

the server at the server side of the VPN tunnel should optionally be able to access one or two devices behind the customer side of the tunnel: so far I solved that by using the tunnel ip of the customer-pfSense and setting up a portforwarding there.

But in the "gen 2" setup we discuss here that pfSense is not the default gateway anymore for the customer-LAN. So I think the accessing server should be NATed to look like an IP in the customer-LAN to be able to communicate without routing (?)

The PCs at the customer side will get a specific route added, that's not a problem. But the ATMs/"Bankomat-Terminals" there aren't capable of getting various routes set.

I will test that next week and see what I can come up with. For sure I appreciate any ideas here ;-) although I start feeling guilty to somehow delegate my work somehow ... thanks for this discussion! good morning (in my part of the world)!

sgw

Continued my work on this and I see progress:

removed the IPSEC- and AWS-wizard, removed all the outbound NAT rules and added only the one you suggested.

I added a portforwarding:

(for testing I use a ssh-rule)

VPN-tunnel-ip-of-1100, port 50022 ... gets forwarded to a "test-system" in the LAN of that box, port 22

That alone isn't enough, I need a rule on the OpenVPN-interface:

allow Port 22/TCP, source Server-IP, Destination "test-system"

That works! And "test-system" sees the accessing ssh-client with the LAN-IP of the pfSense .. so no additional routing needed here. Great!

Looks very good to me!

I will now try to edit LAN from DHCP to a fixed IP: in the target networks I have no admin access to the DHCP servers, so it could be helpful to also be able to run that on a static IP (yes, I have to ask for this static IP also ... I want to have both ways available).

thanks again @viragomann

viragomann

@sgw
The idea of configuring the LAN as DHCP client was to get maximum flexibility. The device doesn't need a static IP for what you're aiming and if the remote sites admin want to assign it a certain IP for whatever reason he could do this by a static mapping.
But for sure you can also go with a static IP.

sgw

@viragomann I agree. Tested with static IP on LAN also, looks good.
The test box is on the way to the customer, for the next stages of testing.
Thanks again.

sgw

Unfortunately I have issues with testing this.

The box is connected at the home of their coder.

The box gets DHCP-IP, connects to OpenVPN, everything up ...

I search for around 3 hrs now:

He adds a route on his windows PC, and tries to ping a server at the server site.
I packet capture on both pfsenses:

the openvpn server side and the openvpn client side

The ICMP request gets to the target server, I see the reply packet on the LAN interface of the OpenVPN server pfSense ... but NOT on the tunnel interface.

The reply gets routed to the internet and NOT into the tunnel (on the ovpn-server-machine, to be redundant).

The routing table looks correct to me.

I can replicate that with MTR. And I don't know the reason.

I can add the subnets etc if helpful

sgw

more details, sorry for flooding:

openvpn-client-side: LAN-IP: 192.168.8.57

the client gets access to this server-LAN via CSC: 192.168.1.0/24

I see routes created on the server:

192.168.8.0/24 via ovpnc1 ..

There is no 2nd subnet like this at other ovpn-clients, I double-checked that.

Route on the ovpn-client-pfSense:

192.168.1.0/24 via ovpnc ... ok as well

I can ping the LAN-IP of the ovpn-client-pfsense from the ovpn-server. But NOT from LAN.

firewall rules checked, windows-firewall (the server machine to be reached is MS Windows Server) disabled for debugging

This is quite confusing right now

sgw

I installed mtr on the ovpn-server.

A ping to the LAN-IP of the ovpn-client should go through the tunnel, I also see according rules in the ovpn-routing-table. But not in the general routing table ... I assume that's correct this way, it looks similar for the ~20 other ovpn-clients.

The mtr run shows that the ICMP-packet is routed to the default gateway instead.
That's wrong.

viragomann

@sgw
On the OpenVPN server you have to specify the remote networks correctly to get the routes set.
And also you need to create a client specific override for the client and as well specify the remote networks there.

Are you missing these settings?

sgw

@viragomann thanks

no, I have these ... see the CSC:

in IPv4 Tunnel Network I set a specific Tunnel IP for that client: 172.31.0.121/23
in IPv4 Local Networks I add the server side LAN to be reached: 192.168.1.0/24
in IPv4 Remote Networks I have the client side LAN subnet: 192.168.8.0/24

That's all. I do it like this all the time for ~20 clients ...

This client is only different in using only LAN.

On the client I see a route to the server LAN in Diagnostics/Routes.
On the server the routes to the ovpn-client-LANs are not there, but visible in Status / OpenVPN / Routing Table

And they look similar for a working and that non-working client:

sg1100_19	88.xxx:30322	172.31.0.78	2025-04-11 12:36:43
sg1100_19	88.xxx:30322	192.168.118.0/24	2025-04-10 13:03:28
sg1100_21	185.yyy:23417	192.168.8.0/24	2025-04-11 12:30:27
sg1100_21	185.yyy:23417	172.31.0.121	2025-04-11 12:36:43

That's the strange thing: it looks correct.

sgw

@viragomann said in set up pfSense as additional gateway into VPNs:

On the OpenVPN server you have to specify the remote networks correctly to get the routes set.

I define that in the CSCs for the clients. The OpenVPN-server itself doesn't have to be adjusted when adding clients, at least as far as I know. I only edit that in the CSCs. Right?

sgw

What I see and what looks suspicious:

the Default Gateway IPv4 on the ovpn-server-side points to a specific gateway and is not set to "Automatic".

For all the other clients it works but the routing for this one client is wrong:

when I mtr from the server to the client side the packets are sent to def gw and not into the ovpn-tunnel

viragomann

@sgw
As mentioned, client sites networks have to be specified once in the server settings at "remote networks" and again in the CSO.

If they are missed in the server settins pfSense doesn't add routes.

sgw

@viragomann

I don't see where to add that, and I didn't do that for the other clients.

VPN/ Server/ OpenVPN/ Servers/ Edit ?

used Search in Browser, not found ;-)