@viragomann yes, that is what that rule is doing on the sonicwall, s-nat and d-nat on the same rule while also matching a port/service. as you suggested the way to do that on pfsense is to use both port forward and outbound nat to achieve the same. the thing is: there's hundreds of those rules, and they will need to be maintained in the future, effectively doubling each sonicwall rule while migrating them to pfsense will make maintenance much harder. My IT manager suggested looking at using 1:1 NAT rules and dealing with service/port matching in a different ways, maybe something can be done to effectively do that using firewall rules or policy routing. I'm in the process of exploring those options on a test deployment in our lab, any suggestion towards that would be greatly appreciated.

And you also need to do this for all domains hosted on local mail servers. And also manage this and external dns changes as needed.

i resolv my problem now i face auther issue

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.