Will Miles wrote: > Hi, > > I ran in to this one too. The basic issue is that jabber leaves its TCP > connection open but idle when there's no actual messaging traffic going on, > and pfSense's scheme to implement NAT reflection (ie. accessing the "public" > IP address from the LAN) depends on the use of a TCP proxy that has a fixed > timeout (although IIRC there's currently a hidden option that allows > adjusting the specific timeout). In this case adjusting the state timeout > won't help because it's not the state table that's timing out - it's the TCP > proxy. > > The quickest "fix" is to use the DNS proxy on your pfSense box and set a > fixed mapping of the external name to the internal IP of the server. This > forces the internal client boxes to connect directly, and still allows > external clients to operate normally through the firewall (since they resolve > DNS against the public DNS servers that carry the correct external IP). > > Another "fix" is to adjust the TCP proxy timeout - I'm not sure where that > lives currently, although IIRC it's not accessible from the GUI; the details > are in the forums somewhere. Unfortunately, this can lead to dead proxy > processes kicking around on your pfSense box for long periods of time before > they time out, but at least the live connections don't go with them. > > The Linux kernel supports doing NAT reflection directly in the kernel, which > is why it 'just works' with IPCop. Unfortunately, the FreeBSD gurus claim > that their NAT system is not capable of doing this within the packet > filtering framework. That said, it /is/ possible to trick it into behaving > this way, and I assembled a patch for my own usage to solve this specific > problem, but since the experts claim it's not possible there's no guarantee > it will behave correctly in all circumstances. I'll see if I can get it > together over the weekend - I'm still using one of the 1.2 betas, though, so > it'd take me a bit to update it for the RC build. That said, it doesn't > remove the proxy-based reflection scheme, so if you're interested in the > patch you can always go back to whichever model you find works best for you. > > -Will Miles
Thanks for the detailed explanation Will. We'll try adjusting the tcp proxy timeout. I think we found some sort of timeout setting we tried to set in the config file, but I'm not sure it was the tcp proxy timeout. And when we tried it, we hand hacked the xml, and broke the syntax (didn't close a tag), which confused us. We've reverted to IPcop until we can schedule another maintenance window to sort this out. Cheers -- Geoff Crompton Debian System Administrator http://www.strategicdata.com.au Phone: +61 3 9340 9000 Fax: +61 3 9348 2015 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
