It turns out that the old server was running a version of FOP2 that did not have the --revoke option and therefore wasn't releasing the key, so when attempting to register the new server FOP2 wasn't acutally getting it's key and restarting properly.

Well, that's exactly the issue. It is a socket error, but I can see the initial SYN packet hit the server and the server sends back an [RST, ACK] every time. It repeats this behaviour about 10 times before the FOP on the browser says, "System is not available right now"

I can verify that the SYN is received by the server unaltered except for the IP address due to NAT and I can verify that the RST, ACK is received by the client browser also unaltered save NAT translation.

It only asked me for the username & password after I reloaded when I had installed the license. It doesn't repeatedly ask for username & password. Once you enter the username & password, it does the connecting to server X until timing out. I'm just not sure if somehow or another my firewalls are missing something to alter the interior of the packet that is received by the fop_server in order to keep it from freaking out. I also wonder as it seems to happen to each client after the client reloads an active session. Any time after this, each FOP client cannot reconnect. It's almost like something in the cache is messing up the client's initial authentication request and the server is RSTing the connection because of a malformed packet.

I've just installed FOP2 on a new server and installed our license. I have been unable to get past the login screen. The strange thing here is that when I initially reinstalled and connected, I could log in once and install the license. After installing the license FOP2 seemed to hang and when I reloaded the page, it asked for username and password again, which seemed usual, then just hangs on connect.

After doing some packet cpatures, I have verified both from my desktop and from the FOP2 server, FOP2 sends an RST, ACK packet after the initial SYN to port 4445.

I went back to the old server running it with the previous version of the fop2_server and it is now doing the same thing. I can include copies of the packet captures if necessary. I've got firewalls on both ends and have verified that the packets are not getting mangled somewhere and the TCP stream IS getting through.

The old server has a direct, public IP with standard iptables. The new server's firewall is an Endian Community UTM device using iptables & snort (disabled for the moment to eliminate possibilities). The firewall for the desktop is also Endian Community UTM with snort enabled (but the wireshark & tcpdump from the server indicate the packets are identical save the NAT translation info).

I'm a little confused as this started for me around November when I installed my Endian at the desktop side. I didn't think much of it as outside the Endian I could still access the FOP from the old server. Then the other day, the old server started behaving the same as the new server behind the new firewall.