NAT Reflection (Pure NAT) not working for same subnet (v2.2.2)
-
@johnpoz said in NAT Reflection (Pure NAT) not working for same subnet (v2.2.2):
Maybe its a bug for when people use insane masks and try and do nat reflection ;)
Perhaps, but seems unlikely. Especially given that the OP seems to have used 10.121.12.0/24.
-
The OP was using version 2.2 of pfsense.. So whatever has ZERO to do with today... Unless your using version 2.2 of pfsense?
Thought you said pfsense IP was 0.1 here there are nat rules to 0.2
no nat on igb1 proto udp from (igb1) to 192.168.0.2 port 53
-
@johnpoz said in NAT Reflection (Pure NAT) not working for same subnet (v2.2.2):
The OP was using version 2.2 of pfsense.. So whatever has ZERO to do with today... Unless your using version 2.2 of pfsense?
Nope, I am using 2.4.5-RELEASE.
These get created when I do nat reflection, just did another one for 6666 port
Again, I believe that it works for you.
But, it does not work for me.Thought you said pfsense IP was 0.1 here there are nat rules to 0.2
This is unrelated to the issue at hand.
0.2 is my DNS server.
0.1 is pfsense. -
Have no idea what else is unique to your setup... Someone using a /18 mask prob has all sorts of nonsense setup ;)
-
If anyone is interested in debugging this at a later date, please let me know.
I am very interested in working with anyone who has any constructive ideas for how to move forward.For now, the hack I described above, (The manually created outgoing NAT rule) seems to patch over the bug, so I will go ahead and use that.
Cheers
-
@rossc719 said in NAT Reflection (Pure NAT) not working for same subnet (v2.2.2):
seems to patch over the bug
There is no BUG.. The problem your seeing is something unique to your setup.. More than happy to help you work through it.. But as I have shown, I can not reproduce your issue. The problem is something unique to your setup.
-
More than happy to help you work through it..
Excellent. How would you like to proceed?
-
FWIW, I'm still interested in trying to work through it with anyone who is up for it.
I guess I'll stop updating this thread, but if someone is reading this in 2028, and is interested in helping, please assume I am still interested.
-
Old thread, but in context on an edge case bug I think an update is relevant - I have just been having this exact same issue, and @rossc719 's input on this thread plus the document he contributed (https://docs.google.com/document/d/1DCtqI2q3RlaK6HkTgp_xFw6poxWg6wiJlzw0V7lDtGU/edit?usp=sharing) was exactly what I needed to fix it.
I have version 2.4.5-RELEASE-p1, the 'Enable automatic outbound NAT for Reflection' tick box is definitely set and, for whatever reason, does nothing. TCP dump showed all the traffic traversing the NAT correctly, but retaining its original source address. I added in a manual outbound NAT and the problem is fixed straight away.
-
@andy_redpoint Exactly my experience. I was testing OPNsense 21 with this configuration and had no issues. Rebuilt with pfSense 2.5.2 last month and spent a good hour or two trying to work out why the same settings weren't working.
I would add that the other "hacky" thing I'm doing is bridging the interfaces of a dual port NIC and assigning the bridge to the LAN interface. But I have turned off filtering for the bridge members.
Thanks for all the posts on this thread and the consideration for future Googlers @rossc719 with your outbound NAT solution which has resolved my issue. Reflective NAT isn't ideal, but it least it works until I can do something like build a reverse proxy in front of my web servers.
-
Hello @rossc719 we have not passed 2028 yet and I ran into the same issue. For me I did not have Enable automatic outbound NAT for Reflection selected, but I did have Pure NAT selected for NAT Reflection mode for port forwards. However, after enabling Enable automatic outbound NAT for Reflection nothing changed, it still was not working. It was not until I forced a filter reload after enabling that option that it started to work.
-
Good to know.
But, at least for me, reloading the filters makes no difference.
My situation has not changed since I originally posted it back in 2020. (Needless to say, things have been reloaded, rebooted, and reconfigured many times since then).
I am still using the same manually created outgoing NAT rule to patch the "undesirable behavior that is apparently not a bug". :-) -
I did find another solution to this problem, and it is no more harmful (I believe) than the default operation of a firewall if done carefully. It could possibly be fine-tuned somewhat, by placing this rule at the bottom of a rule list. I'm sure others here will advise. I only needed mine to transfer a few email accounts, to new email server software that had been installed. It needed to be run on the same server, and I had to use the reflection used for incoming external email, to get out of the machine. Once done, I disabled the rules.
I created a rule for the VLAN for our mail server to allow All outbound traffic through the firewall to the web, reflection redirects it back again if it's on the same ports as per the inbound NAT rule.
Action Pass
Interface MAILSERVER
Address IPV4
Protocol: TCPSource: Single host or alias, Mailserver_ip
Destination …
**Invert match: Checked
LAN.net ← Lan for users – this blocks the email server from connecting outbound to the main_lan via reflection
(You may need to set a rule for each VLAN if you intend to run it permanently, I had to do another for our phone system)And that's it.
I hope it's useful to someone.
Mike
