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 On Wed, 26 Sep 2007 12:39:34 +1000 Geoff Crompton <[EMAIL PROTECTED]> wrote: > We've just transition from using IPCop 1.4.13 to using pfSense 1.2-RC2. > The transition wasn't so bad. However we are having problems with jabber > connections now. > > Our ejabberd (version 1.1.2-6, from the Etch Debian package) runs inside > a vserver in our dmz zone. Our domain name jabber.strategicdata.com.au > resolves to the IP address on the WAN interface (not an Virtual IP). We > have configured NAT rules to port forward the connections to the > ejabberd vserver. > > This works for clients connecting from the Internet. It also works for > clients connecting from the LAN that connect directly to the vserver > address. > > However if a LAN client connects to jabber.strategicdata.com.au, and > hence to the public IP address, they can connect, and they get > disconnected a few minutes later. > > Does anyone know how I can debug this further? > > The ejabberd logs currently show that the dropping clients have a source > IP address that corresponds to the dmz interface IP address on the > pfSense router. The logs from when we were running IPCop 1.4.13 showed > that ejabberd saw the connections coming from the LAN interface IP > address. I'm not sure if this is significant, because in both cases the > IP address doesn't correspond to where the client really is coming from. > > -- > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
