UDP NAT Problem : Random NAT bug ?
-
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.
