Nat Reflection
-
Hello. I have a NAT Reflection issue. I am not sure if this is a bug, a new feature, or a change in behavior. This was working fine in 2.2 but after i upgraded to 2.3 it broke. I can access the NAT externally without any issues, but when i try to hit the NAT address from a LAN, i get connection timed out.
-
bump
-
it is a bug… normally happen if you use traffic limiter, but probably not only then.
-
Is there a bug id i can reference? i just upgrades to 2.2.4 hoping this bug was squashed but it looks like it remains. any suggestions on how i can determine or work around the bug?
-
I am not sure if that was a serious answer or not…. i somehow doubt it.... but anyways....
That would be great if i ran two separate DNS zones, one external and one internal. But that isn't possible since i run a single converged AD forest.
I will change the question a bit, What can i do WITHIN PFSENSE to troubleshoot this and locate a work around? Is there a pfsense or freebsd bug that i am hitting , that i can reference?
-
It it wasn't for your Karma on the forum, i would ask if you had any clue what you are talking about?
i am asking about nat reflection and you are off in left-field talking about DNS. So how about you either put your skills to use , and help answer my concern/question.
or you post to some else's thread and waste somebody else's time? Seriously dude.
If you want to help, explain why this isnt working, steps i can take to continue to troubleshoot it, and ideas on how to fix it. I am open to being a good community member here.
Telling me to stop using a feature, which has a legitimate purpose, for situations like my own design, is condescending and frankly rude.
So either help, or go away.
-
i am asking about nat reflection and you are off in left-field talking about DNS. So how about you either put your skills to use , and help answer my concern/question.
Sure. And the docs are off as well…
Telling me to stop using a feature, which has a legitimate purpose, for situations like my own design, is condescending and frankly rude.
Your design has broken DNS records, pointing to places where the service is not to be found. And instead of fixing it properly, you are playing ping-pong with packets.
-
I know how to search the wiki, and that document i have read. Thanks for pointing it out.
Your design has broken DNS records, pointing to places where the service is not to be found. And instead of fixing it properly, you are playing ping-pong with packets.
This device works via ip address not DNS. It does not support DNS resolution, so split DNS is of no assistance in getting a resolution to my issue.
thanks for the help, i am open to suggestions at this point, if you have anything i will be glad to try it.
-
I must be missing something. So you don't use DNS, and who's forcing you to put a WRONG IP into the device?
-
We need to access this from both our internal network (10.0.2.X) AND Externally via the NAT via a Single ip address, instead of having to reconfigure it everytime we leave the office for a public ip, instead of the private internal ip .
-
Yeah, that's what DNS is for. Sorry, I don't get it. None of your devices supports DNS, or…
-
Exactly like my, and this is why I still use v2.1.5… with every new version it look like pfsense regress and not evolve, one step in to the future two steps back. ( stay with your working version and do not upgrade in production unit )
-
Unrelated to the issue, but switch to pure NAT mode reflection first, it's just much cleaner and more scalable.
Then filter on states of the reflected traffic, what do they show?
-
Exactly like my, and this is why I still use v2.1.5… with every new version it look like pfsense regress and not evolve, one step in to the future two steps back. ( stay with your working version and do not upgrade in production unit )
You have no idea what you're talking about. Upwards of 2000 systems now on 2.2.4, the majority of systems on 2.2.x.
-
it is a bug… normally happen if you use traffic limiter, but probably not only then.
If you're using limiters on interfaces where NAT is applied, yes that's an issue. But there is no other circumstance where this is a problem.
-
If you're using limiters on interfaces where NAT is applied, yes that's an issue. But there is no other circumstance where this is a problem.
Interesting! I could not find this unique bug listed on the pfsense forum anywhere. Is there a central repository of "dont do this or you will hit this bug"?
That being said, i DO have some devices on my LAN which have limiters applied to them. Neither, Source nor Destination address fall within that limitor range of the devices i am having issues with though.
so if i understand correctly, you are saying, even though i have a list of 3 addresses which have limiter applied to them on the LAN interface, and even though the devices i am having issues with are NOT using that limiter or that firewall rule, i may/am still running into some weirdness within pfsense?
if that is all true, besides removing the limiter, are there any other work arounds or hacks i can use?
-
removing the limiters is worth a try to confirm or deny whether that's the issue.
The bug in question is https://redmine.pfsense.org/issues/4326
In most configurations, that only applies to using limiters on WAN rules. Where you're using reflection that's more complicated as you're doing NAT on LAN and there are more possibilities for that to apply.