NAT Reflection (timeout problem)
-
I forgot to mention this is happned only when host is one of local computers…
-
I have no idea, sorry.
-
The problem with the NAT relfection is that your requests from the local network are going to pfsense box and then back to the game host. This is laggy as the nat reflection is more of a hack. All you have to do is have people outside your network join the game with your internet address. People inside the network join the game with the local private ip for the machine. Problem solved and you can leave nat reflection on or off depening on if you use it for other things.
-
Hello again!
I still didn’t solve my problem with NAT redirect rules. Problem occur when PC1 or PC2 create host for Warcraft 3 Frozen Throne on Battle.net. Direct IP connection for that game isn’t possible. I need to enable NAT redirect rules options in advanced system setting if PC1 or PC2 (one of those is host, other is joining into the game) wants connect to hosted games. Problem is that when joined player (PC1 or PC2) is in hosted game after few second in it he drop out, but other users form WAN have no problems at all. I think there is a timeout problem in NAT redirect rules. Is there any way to solve this? Sorry for my bad English.PC1 and PC2 are computers on my LAN behind PFsense firewall. There is also no problem if host is one of WAN users.
-
Not sure if this actually might have an effect on this but try to check the "static routing" option at system>advanced.
-
Hi all,
Not sure if anyone's still following this, but I ran in to this problem myself. I installed pfSense yesterday, rigged 'er up for my network, and then found that my jabber server was dropping and reconnecting every few minutes. I tried the fixes recommended here with no success, so I started digging about to find out how NAT reflection is implemented and configured under the hood.
As it turns out, the netcat sessions used for NAT reflection are spawned with a 20-second idle timeout which is not configurable. Of course, using a higher timeout means a greater likelihood of dead netcat sessions kicking about on one's firewall, so I'm not convinced that simply tweaking this value is the right answer here.
I'll post back later after I've had a bit longer to play with it - there's got to be a better way of implementing NAT reflection!
-Dhauzimmer
-
We followed the standard way:
http://www.openbsd.org/faq/pf/rdr.html
But by all means, feel free to make a better solution!
-
Thanks for the link - invaluable information for a BSD newbie. :)
I've cobbled together a solution that is based around the fourth ("not recommended") pattern - it uses tagging to ensure that only relevant packets get mangled by the return NAT rule. Before I pass it along, though, a quick question: This solution will use two 'states' instead of running TCP proxy daemons. Will that consume more CPU/memory/other resources?
I also haven't fully cleaned out all the spawn-inetd stuff, nor have I thoroughly tested the fix for all possible cases. I did a bit of cleanup on the surrounding code, though, and added a clause to suppress issuing redirect rules for interfaces that are currently disabled. There may also be some cross-interface issues if you've got optional interfaces involved; I didn't do a thorough analysis of all the possible permutations. However, it has the up side that it will properly handle large port ranges at no extra charge.
If you're interested, where would I go to submit a patch?
-D
-
Patches and the format can be found here http://wiki.pfsense.com/wikka.php?wakka=SubmittingPatches
We absolutely appreciate patches.
Thanks!
-
This timeout issue is causing me a lot of heartache as well.
I've just replaced a WRT54G running DD-WRT with a pfsense box (VLAN-based one-armed router) and everybody is complaining about ssh timeouts and the like. 20s is way too short.
In my case, making that timeout an hour wouldn't hurt much, since there are about four forwards on the box, and I can't see more than a few connections to each. Certainly consuming two states is a non-issue.
I really like the other features of pfSense, but unfortunately this could be a dealbreaker for us.
-Zandr
-
This timeout issue is causing me a lot of heartache as well.
I've just replaced a WRT54G running DD-WRT with a pfsense box (VLAN-based one-armed router) and everybody is complaining about ssh timeouts and the like. 20s is way too short.
In my case, making that timeout an hour wouldn't hurt much, since there are about four forwards on the box, and I can't see more than a few connections to each. Certainly consuming two states is a non-issue.
I really like the other features of pfSense, but unfortunately this could be a dealbreaker for us.
-Zandr
Maybe turn on SSH keep-alives? Putty supports it and so does ssh.
-
Maybe turn on SSH keep-alives? Putty supports it and so does ssh.
That takes care of SSH, and we've done that, but we have other applications (our software) that expect idle connections to last more than a few seconds.
Even just making that configurable would be a huge help.
-Z
-
Okay, I added a hidden option for controlling this.
edit config.xml by downloading it via the webConfigurator backup feature.
add a <reflectiontimeout>100</reflectiontimeout> area to <system>So it should end up looking something like:
<system><reflectiontimeout>100</reflectiontimeout>
Upload the changed config.xml … The firewall will reboot.
This will show up in about 2 hours after the snapshot server rebuilds the images.</system></system>
-
Outstanding. I'll grab a new image in the morning. Thanks for the super-fast response.
-Zandr
-
Very nice this thing also works for me. Will be this features also integrated into GUI?
-
Very nice this thing also works for me. Will be this features also integrated into GUI?
Doubtful.
-
I never followed up here… This is working great. I set it to 3600s (1hr) and all of the issues with our other apps have gone away.
We only have a few forwards anyway, so I'm not too concerned about the resources consumed by those nc's.
I'd second the suggestion to tuck this into the GUI somewhere, it's a pretty useful feature. Though, if it were superseded by Dhauzimmer's patch, that could be even better.
Thanks again.
-
Will consider the GUI option after I pass it by other devs.
The patch was submitted to coreteam but had the potential to break QOS and Multi-Wan so it is not quite ready yet. This is going from memory.. I am terribly sorry if I am confusing two different incidents.
-
Will consider the GUI option after I pass it by other devs.
The patch was submitted to coreteam but had the potential to break QOS and Multi-Wan so it is not quite ready yet. This is going from memory.. I am terribly sorry if I am confusing two different incidents.
Why not just default it to 1 hour? I'd rather not see yet another knob that people will twist for no good reason exposed.
–Bill
-
I am perfectly fine with this as long as no DOS potential is present?