set up pfSense as additional gateway into VPNs

viragomann · Apr 3, 2025, 4:45 PM

@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 · Apr 3, 2025, 4:45 PM

@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?

login-to-view

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 · Apr 3, 2025, 5:18 PM

@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 · Apr 4, 2025, 5:08 AM

@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 · Apr 7, 2025, 7:56 AM

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 · Apr 8, 2025, 6:11 AM

@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 · Apr 8, 2025, 6:11 AM

@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 ;-)

sgw

currently it seems to work after adding a NAT outbound rule on the client

OpenVPN 192.168.8.0/24 * 192.168.1.0/24

we test now

sgw

That outbound rule editing changed something, as if there was something changed under the hood.

Right now the admin there is able to access systems on the other side of the tunnel, as intended.

Nothing changed on the OpenVPN server, btw.

That NATing isn't fully correct still

What I'd like to have:

server side IP should be able to ping a PC on the client side
server side VM should be able to access a system on the client side, with a mapped IP in the client LAN

currently I have this, and rebooted for a check, the admin is able to access a server VM via RDP: GREAT, but not 100% yet ;-)

login-to-view

THANKS so far, I think I need some time afk now soon

viragomann

@sgw
Yeah, outbound NAT rules (masquerading) can be used to circumvent missing routes.
I'd rather set the routes properly, but depends on the use-case.

sgw

@viragomann I agree but I repeat: where to set these routes? See question above. Thanks.