UDP NAT Problem : Random NAT bug ?
-
Thanks for responding.
I'm not sure but i think this is a different problem, you say you can't reproduce your bug on your secondary FW while mine is reproducible on the secondary, my TCP sessions does'nt seems to have problems too.
hard to say if this is relevant, maybe the "NAT bug" is a default behavior when the Pfsense doesn't know what to do, it may not be directly related to the root cause.
-
I can now reproduce it on the secondary
It happens very rarely on the secondary but it still happens.So, now we have two users with the same NAT problem.
You are also using pfSense 2.0.2 like I am.
Also, I have been using pfSense in production since 2010. -
Sounds like this:
http://redmine.pfsense.org/issues/958 -
Just upgraded to 2.0.3 : same problem.
Indeed it seems related to this old issue, but i'm not using floating rules.
PS : jimp, thanks for writing the PFsense Guide, excellent book ;)
-
Interface group rules could also cause that. Or if your WAN or WAN2 don't have a gateway selected. Or if you've somehow otherwise disabled reply-to.
-
Interface group rules could also cause that.
I don't use them neither.If your WAN or WAN2 don't have a gateway selected.
Gateway selected on both wan.If you've somehow otherwise disabled reply-to.
I don't see how to make this, could you please explain me how to check it is well enabled ?Although, in the old bug, it seems reproducible (as far as i understand the syn ack is always on the wrong interface).
In my case, it actually works for some time before giving weird results.
I just need to kill the states to temporarily fix the problem.This is because i'm not sure it's something "disabled" but really a bug.
BTW, thanks for taking of your time for me.
-
"reply-to" is in the System -> Advanced -> Firewall and NAT menu
-
Thanks.
the box isn't checked, so i assume it's not disabled.
(FYI, have tried to set the Firewall Optimization Options to conservative, but same results).
-
Just upgraded to 2.0.3 : same problem.
Could you check with pfsense 2.1 ?
Btw Firewall Optimization Options => conservative only increases the state timeouts for TCP & UDP. It would be handy if you'd want to keep a UDP NAT state with a long period between "ping" packets. You can check your system's values with pfctl -st
-
We'll need to see the full /tmp/rules.debug to tell much more.
-
Could you check with pfsense 2.1
I'm sorry but my firewalls are in a production environment, i can't use beta versions as any devs problem would have major impact.
If this is the only way to investigate, i would have to build a test case in a lab but i don't know when.Btw Firewall Optimization Options => conservative only increases the state timeouts for TCP & UDP.
I suspect a miss function in the way UDP sessions are handled.
As you certainly know, UDP isn't really statefull, so Pfsense has to work on "unperfect" sessions.
I was assuming that Pfsense (after some time) was considering my udp stream as a new one and treat it differently (in that case, without nat and on the wrong eth).
As TCP has no problem, i was thinking it was a good idea. that's why i tried the conservative mode, it seems i was wrong.With the pfctl -st, i will check if my "random problem" becomes more reproductive, thanks !
I will send you the /tmp/rules.debug as soon as possible (a pm will be ok ?)
-
I've just checked the file content, i'm sorry, but /tmp/rules.debug contains way to much private data, i'm sure you will understand that i can't send it to someone without some serious NDA.
In order to let you investigate properly, i will try to reproduce my problem in a lab, i'll come to this topic as soon as possible.
Sorry for the delay.
