Not sure if this will still help you or not. I found myself troubleshooting the same issue with Mullvad Port Forwarding and came across your post. I eventually overcame this problem by leaving the route pulling options unchecked and allowing the Mullvad routes into my routing table and using using "policy based forwarding" on my to direct traffic on my LAN interface.
You can create (or use the existing) firewall rule that allows traffic out of the LAN to the WAN. On this rule use the advanced options drop-down to specify the gateway on your primary WAN interface.
This is not an ideal workaround as the default route for the firewall is still set to use Mullvad and this can have some unintended consequences, but it will allow you to use port forwarding on your VPN client.
Hope this helps. I'd be interested to know if you ever came up with a solution of your own.
Well split your /28 into 2 /29.. So for example
41.0.0.0/28 = .1 to .14
41.0.0.0/29 = .1 to .6 (lan IPs)
41.0.0.8/29 = .9 to .14 (vip IPs)
Use either of those as your network behind pfsense, and then use the other as VIP IPs that you nat with..
Depends on how many IPs you need behind... You could also just use them all as VIPs and use everything behind on rfc1918.. Just because they routed the /28 to you doesn't mean you can't just use them all as VIPs on and do everything behind a nat.
On ours we do have WAN rules allowing IP4+6/any traffic to the internal IPs referenced by the 1:1 NAT. (those then have their own router with their own rules) Sorry if I missed that, it may be 15 years since we set it up, and it was on m0n0wall back then not pfSense. :)
I have not tried to do 1:1 using a different interface as we are using a private IP range on LAN and each tenant (including our 1:1) has their own IP.
What is your Outbound NAT Mode set to?
For the OPT2 interface if it had no rules it needs at least a rule allowing outbound traffic (from OPT2 to any). In our case we have DHCP turned off and disabled the default LAN to any rule so only whitelisted IPs (tenants) are allowed.
Security though obscurity is not security... Opening up rdp to the public internet no matter what port is a BAD idea!!! If you want to rdp to this box, then vpn in and then do it.
In cases like this I would try enabling the "Log packets matched from the default block rules in the ruleset" option in the log settings temporarily and see if something else is blocking the traffic. For remote mobile apps I believe 3CX just needs port 5090, since for the servers we host in our data center we have just that and the management port 5001 open.
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.
Yep, that ^. You can't split a /64 without expecting all sorts of problems.
You could set a very specific outbound NAT rule to workaround the asymmetric routing you would otherwise have with a device that isn't using pfSense as it's gateway. It would be better to avoid it but if you have no other option it could be done.
Steve
For nearly a year now, we have multichannel numbers and 800 numbers from Hottelecom. When it was connected, it was a problem, but not significant, so the support service instantly decided everything. Have you contacted the support team?
You should check if you can see a mac address assigned to the IP entry in the arp cache of the host you're trying to ping.
No surprise that you can see the firewall's own interfaces in the arp cache. They're static.
Go check the arp cache again and then fix the l2 plumbing.
Cu
Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
