@auroramus The source port of the requests is not specific, it's dynamic and can be any. So you have to set it to "any". To avoid that pfSense show its web GUI when access it, change its listening port in System > Advanced> Admin Access to another one.

@vortex21 said in Reflection NAT using WAN Address as Source IP: I have configured Reflection NAT in my lab to test a DNS View problem. The DNS server is configured with an internal LAN IP address and has two DNS views, all queries from the internal lan are processed on the DNS Internal view. I'm wondering about the reason for using NAT reflection. Why don't you simply forward packets to the DNS servers. Is possible to get Reflection NAT to use the WAN address as the source address or do I have to create individual NAT rules? Yes, you will need to add an outbound NAT rule for that. You might have to switch into hybrid mode if the outbound NAT is still working in automatic. Add a rule and limit the protocoll to TCP/UDP and the port to 53 (or even 853 in case of DoT) and enter the DNS servers IP at destination, go down and select the WAN IP from the Translation address drop-down. Anyway, when forwarding DNS requests, an outbound NAT rule will be needed as well.

@lasergecko said in Second IP Address - Everything works except for one program/PF: For some reason, it looks like pfSense is prohibiting just Dev from reaching the Prod FQDN, but just via that method. The only one part where pfSense can affect the FQDN is at DNS resolution, if you use the DNS resolver. But since you say it resolves correctly, I cannot think of any issue with pfSense. As I got you, the only problem is to access the dev server from within the same LAN. However, this traffic doesn't doesn't pass pfSense, when the host name resolves the the servers internal IP address. So I think, you should look for the reason on the server itself. Maybe its firewall is blocking access from LAN, maybe the server have set a wrong network mask so that he is sending responses to the gateway. Possibly you can sniff the traffic to find out more about what's going on.

@steveits Ah, yes. Good point. So I guess the corresponding NAT-rule did not work while the forward was fine. I used tcpdump on the proxmox host to find out, that the vserver answered the TCP-SYN, but the pfense did not forward to the corresponding recepient. When I edited the port forward and pointed the same port to the different IP, the handshake succeded. I used netcat listeners on both systems and used an otherwise blank system. So, I am at a loss why it worked in one case but not in the other. Still, it could be external hypervisor rules. But rest assured, I checked them and they all applied to both IPs due to a /24 subnet.

@steveits thank you. I will take a look at the documentation. take care and have a great day. Regards, Mon

@johnpoz said in [44158 Port forward doesn't seem to work] As to switch to secondary wan? For a port to be forwarded, pfsense needs to see the traffic hit the interface you setup the forward on.. How your overall network is setup - have no idea, or what you might have in front of pfsense that could limit something from the internet talking to a pfsense wan IP so it could forward traffic. of course i made the NAT forward/outgoing and rules per the above but using the wan2 interface in place of wan one. the rules must be good, because when i switched, the device immediately went from symetric nat to none wan2 connects to a cable modem so received the ip from the isp on the pfsense interface. that is the address i see on the hnt public ip address. wan1 has a fritzbox connected via eth to a fibre converter. the ISP provides a pppoe connection with a vlan. (tried a direct connection using pppoe with j1900 but performance was terrible) The lan side of the fritzbox has a 192.168.x.x connection and the pfsense wan1 plugs to that. the hnt device public ip is the isp address on the fritzbox fibre converter side.

@fourie777 Look at you badasses sorting it out this long after the original post. Good work.

@martijnvw pfSense is really quite flexible but not so much a "click a checkbox" type of system. Give it some time and I expect you'll like it. And learn a lot as you said. :)

@viragomann said in Port forwarding problem (I did try following the troubleshooting guide): Run Diagnostic > Packet Capture on WAN and initiate an access from outside to check out, if the DMZ is working. From what I see til now, I don't think so. Problem solved, my ISP enabled DMZ on the wrong router (that I have an account for). Cleared up the router details, DMZ now working and port forwarding works perfect. Thank you for your time!

@seantree After removing the check and saving the interface settings, the block rule should be gone from WAN. Additionally you need a pass rule for allowing the access. However, this should be added automatically by the shown port forwarding rule. Consider that Quick floating rules ca override interface rules.

@felixcda That sounds like the HA setup has its own problems. Scan through the troubleshooting doc and maybe start another thread. You should be able to put the primary in persistent maintenance mode, or shut it off, and the other take over seamlessly. And go the other direction. I do it all the time and it's how updates are done. Your two routers are identical?

Make sure you are allowing your WAN to talk to private ip space. Click on Interfaces, then on WAN, scroll down to the bottom for this: [image: 1650086644664-private_ip.png] If that's checked you are going to have a hard time talking to the external non routable IPs. This particular problem has tripped me up many times over the years when I forgot about it.

Got it! [image: 1650075752016-hq_port_pass.png] I could see the port passing in on HQ. But still no dice. [image: 1650075772951-branch_missing_port.png] I added this accept rule on the Branch side and now it talks! Took me some wandering but now I understand. Thanks @viragomann !

Ignore. I blundered my way through getting it right. Thanks for your time. --Richard

@pacopito22 Yeah, agree. It should use the VIP on WAN. You should reboot pfSense after adding outbound NAT rules. Maybe it also helps to kill the states. But the ping is not going to port 8080. This is TCP protocol as the state table is showing. Ping uses ICMP.

@rafamello said in Pure NAT: For this to work I have to enable Pure Nat in : System / Advanced / Firewall & NAT, correct? Technically, that setting applies to ALL rules. If you only want reflection on some rules, you can leave the above disabled and on that one NAT rule change "NAT reflection" from "system default" to one of the Enable options.