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.

nothing else here, maybe the host have its own firewall blocking external ip? check with packet capture / wireshark if you see the traffic

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.

The problem is solved. The 3cx firewall check of course checks the ports from a different address than my aliases.

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.

Still no clue on what's causing it, if anyone has an idea, it would be grand.

Great! Thanks, @Rico Now its works for me

@johnpoz thanks, its working now.

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

@julienb If you can, check on the other end what IP-address you see there. If it is the one you expect, then NAT is working.

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

@Nono_ A DNS-Forwarder is nothing else than a stripped down resolver. The only difference is that unbound can do more than just resolve. Besides that even dnsmasq can hold host entries nowadays, but anyway...

When you tell a program to use 127.0.0.1 as its source address then the packet filters aren't applied to 127.0.0.1. There's a sysctl variable that needs to be set in order to enable this behaviour.

That's all.