I hate to resurrect an old thread, but this was never resolved for me, and the workaround that I was using is no longer valid due to a change in the situation.
The old thread is here: http://www.mail-archive.com/[email protected]/msg00260.html, but just to quickly recap, I have a web server that sits on the WAN side of a pfsense box and a workstation that sits on the LAN side. The web server is running an ssh server and a wordpress site. The web server and pfsense's WAN both have public IP addresses on the same subnet, while pfsense's LAN and the workstation are on a private subnet, with pfsense performing LAN>WAN outbound NAT. When I tried to transfer a graphic from the workstation to the web server, a few MB go up fine and then the connection stalls until the transfer dies. This is true via http and scp. Less bandwidth-intense traffic, such as web browsing and ssh test interaction did not experience this problem. I control the whole network between the two machines, so my workaround was to add a vlan between pfsense and the web server with a new interface on both endpoints. I added a DNS forwarder host override for the web server so the LAN-attached workstation would resolve the web server to its secondary (private) IP address, thus allowing the workstation and web server to communicate through pfsense but now without NAT. This resolved the problem and file transfers no longer stalled between the two hosts. This worked for a while, but the problem now is that a colleague has installed cpanel on the web server, and when he attempts to load his web site on the workstation he sees only the cpanel default landing page instead of his site. If he disables the DNS override, thus reaching the web server on its public IP address (via NAT), the page loads fine, but we're back to the original problem of transfers stalling out. Re-enabling the override, thus reaching the web server on its private IP address brings him back to the cpanel default page. I assume this is a licensing thing, as cpanel is licensed by its IP address. So I guess my next workaround is to remove the workaround vlan, subnet and DNS overrides I created and turn on advanced outbound NAT. This should have the LAN-attached workstation again accessing the web server by its public IP address, via pfsense's WAN, but without NAT. I believe this will work, but, like the original workaround, it creates unnecessary complexity and ignores the fact that there is a manifest problem with the setup here, apparently directly related to NAT. I would sure like to know if anybody has any ideas. Jim gave me one suggestion that doesn't make sense to me, but I will try it and report back. One other user emailed me privately wondering if I had a solution, so I know it's not just me. db
_______________________________________________ List mailing list [email protected] http://lists.pfsense.org/mailman/listinfo/list
