If you are not using redirect gateway on the remote access server you need to add the 10.0.20.0 and 192.168.1.0 networks to the Local Networks on the Remote Access OpenVPN server.
You also need to make sure those branches know how to route back to 10.17.0.0/24
You need to make sure all firewall rules pass the necessary traffic.
I just saw another system with a down/up openvpn earlier today.
The problem there was one-way traffic.
Traffic could flow from the side that showed down to the site that showed up but traffic could not flow from the site that showed up to the site that showed down.
The tunnel was partially up. Pings sent across from the "down" side would go out the tunnel, be received and replied to by the other side, but would never arrive.
It was a CARP VIP on the down side that the ISP was losing the MAC address for. They would accept traffic from that address but couldn't deliver traffic to it.
Unless you want inbound connections from PIA, then just remove or disable all rules on the OpenVPN tab and the PIAVPN assigned interface tab. Treat it like a WAN interface.
If you do not want OPT1 to access LAN, then place a rule on OPT1 blocking traffic to destination LAN net.
If you do not want LAN to access OPT1, then place a rule on LAN blocking traffic to destination OPT1 net.
Need more details.
In general the trick to port forwarding into pfsense and across OpenVPN to a server on the remote side is:
1. Assign an interface on the destination side. The side with the target server on it.
2. Make sure the rules on the OpenVPN tab do NOT match the incoming, port-forwarded traffic on the destination side. Make sure the traffic is matched by the rules on the assigned interface. That gets reply-to working so reply traffic isn't routed out the default gateway on the destination side.
That's essentially what I did with some Linux laptops I had to issue at my last job. Ran a job that would check for something that should be there, if not then load openvpn. Sound logic.
There are two options.
A. Create a secondary OpenVPN server and keep the two separated.
B. Assign his user a static IP in the pool and create firewall rules to prevent access to your server. Under client specific overides you can add something like ifconfig-push 192.168.1.200 255.255.255.0 to assign his client that IP.
Hi
Screenshot attached.
When the second rule is enabled there is no internet access from the IP specified in Alias Blockpc.
When the rule is disabled internet access is available.
[image: Firewall_Rule.png]
[image: Firewall_Rule.png_thumb]
Yep, that'll do it too :)
Plus, I was mistaken, there is a route to your tunnel network (10.25.2.0/29). However, I was surprised to see it at only a /29… you're only going to get 5 users out of that, but... maybe that's all you need.
Dude your NOT going to change the SOURCE ports of traffic to the same thing.. It DOESN"T WORK THAT WAY!!!
You are completely misunderstanding what they are doing with their 10 port, or your explaining it WRONG!!
If you have some application that randomly listens on some port between 1000 and 2000? And the firewall in front of you will only forward 10 ports then your screwed.. Never going to work..
Hi!
I have default gateway switching enabled but seems it doesn't work. In failover mode I don't see default route in the routing table.
Squid also doesn't work with dual WAN (it use the default gateway). I had it working until recently, but for some time this configuration does not work too.
Maybe these two problems have the same reason. I'm not sure.
Best!
I recently setup openvpn and found similar issues, I decided to check whats my ip and some of the sites are showing my real ip where as others are showing my vpn ip which should not happen in my eyes.
Hi
My script is correctly editing config.xml and client1.conf
OpenVPN is restarted and it appears to connect to the new server, but the GUI still shows the old host address and after a minute or so the VPN appears to be connected back to the old host.
Can this be done?
Thanks
Just use a pfSense instance somewhere on your network to manage your certs ;-)
Though it's not perfectly suited to being a general purpose CA, it sure beats having to mess with EasyRSA.
And on 2.4 you can sign CSRs as well as create certificates.
Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.