@chstechsolutions said in Outbound Nat only 1/2 working: I can run curl api.ipify.org and I get IP address 2 but when I send an email from the server all the headers say it is coming from IP Address 2. Isn't this what you want and what the outbound NAT rule is meant to do?

@wolf3000 They are probably using proxy arp That was discouraged a long time ago, for security reasons. Why would you want that feature ? If using DHCP the PLC should also accept the def-gw info handed out. If using Static IP, it's just one more entry to key in. The whole point of using a firewall is to be "In Control", and not rely on some (could even be a hostile) device, forwarding your packets based on unanswered arp requests. /Bingo

@steveits said in 1:1 Nat routing back to firewall: But he's trying to access the WAN IP from LAN. That seems to me like it needs reflection to work. Yes, you're right. I didn't read correctly. @trever But why are you using the external IP for accessing an internal device? The suggested way is to access it using an FQDN together with internal DNS host overrides. So from within your network the FQDN is resolved to the internal IP and accessing it should be work without NAT reflection.

@steveits Thanks for your reply. I finally figured it out. Quite obvious now that I see it. The ATT box's programming for the "pass-through" mode requires you to enter the MAC address of the NIC that the traffic is being forwarded to. Since the router hardware had changed, of course the MAC had changed. Duh...

@townsenk64 yep, known issue https://redmine.pfsense.org/issues/13126 fix should be in the next snapshot or you can use system patches to apply the commit now

@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.