@viragomann Great tip, that's how it works for me. Thanks you very much for the effort!!!

It appears that "alias-on-given-port" is checked and the invert match of the same alias is ignored so it interprets the alias is used twice and throws the error.

I ended up with a set up using pfBlocker that does work while using invert match on an alias, but it works within the constraint above.

ListA - US
ListB - blocked geo
Technically, outside of these two would be the rest of "all".

Setup:

ListA on port 80 -> machineA port 80 ListA on port 443 -> machineA port 443 !ListB on port 80 -> machineB port 80 !ListB on port 443 -> machineB port 443

@johnpoz The documentation might need to include a note that pfSense does not interpret the invert match of an alias to be a unique from the alias.

The invert match on ListB above is ALL, like you suggested, but without ListB.

Thanks again!

@antiquity2489 I can't but UPnP never was a strength of *Sense. So you better make a port forward yourself.

It has been broken for many years now, so another couple of years doesn't sound too terrible in that perspective. Still, it sucks :(

@stephenw10 @viragomann
through VPN it worked fine. Spent 40 mins and issue solved.

Just to update. Thanks you guys for help anyway

So this is embarrasing...

I have a Mail server that I recently changed the password on my mail account for, this Mail service runs on my home-server.

I got a scheduled powershell script that goes through the logs of this mail service and automatically blocks incoming connections from IP addresses that try to brute force-login or use my mail server as a forwarder. (fail2ban script I made in powershell)

Apparently, since I changed the password to my account, my Gateway-iP (192.168.10.1) was blocked by this script, probably because I had not changed it on my phone.

so it was not NAT reflection that was broken, it was my windows firewall...

will change the powershell script now, to not block my gateway IP :)

also going back to the Ubiquiti Router, as I was able to get IPsec to work there, while I find it very advanced for pfsense

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