FOP2 [RST, ACK] [SOLVED]
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.
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.
Comments
No need to run packet traces. If you enter an extension and password and it prompts again for authentication it means it is not validating your user. So you must check your user configuration and be sure to enter the correct data. If using automatic configuration with freepbx, in the linux console run
/usr/local/fop/autoconfig-users-freepbx.sh
And take note on the user lines, 1st entry is the extension, 2nd the password, You must use those to login. If you see any errors, that will give you a clue on what is going wrong.
HINT for connection problems: if you enter credentials and you are prompted AGAIN and AGAIN for credentails, then the socket communication is working fine, as you are receiving a login incorrect from the server. (note that you are always prompted at load for user and secret, so this applies only if you are prompted AGAIN after trying one combination).
If after entering extension and password you get "Connecting to server, attempt number X", then you HAVE socket connection problems.
Best regards,
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.