I am running Untangle 10.2.0 on a low power microITX system with a 1.8 GHz Atom Dual-core 525 CPU and 4GB RAM. The Untangle server is in router mode with just one subnet on the internal side. It is in a small office with 2 users. The office has an Internet connection through Time Warner Cable at 3x1 mbps. Speed tests confirm that we are getting just below the subscribed bandwidth.
I am having problems when connecting to Adobe Connect web conferencing, used for online training. It will connect and I get audio for 3 to 4 seconds and then freezes, reporting that the connection has poor performance. The poor performance seem to be high latency. (Nothing else significant was happening on the network when these problems occurred.)
Adobe Connect uses HTTP on port 80 and meeting audio and video streams using RTMP on port 1935. If it cannot connect on port 1935, it will use tunneling (RTMPT) on port 80 or 443. The host of the online training forced the meeting to use RTMPT on port 443, which is known to put more of a load on the network. For more on the ports used, see http://helpx.adobe.com/adobe-connect...y-connect.html.
I added a network bypass rules for RTMP (port 135) over TCP and can connect for about a minute before getting disconnected. This supports my theory that the Untangle server is not able to keep up--it works for a while and then gets too far behind. I added a network bypass rule for port 443 over TCP and was able to stay connected. (Of course, I do not want to leave the latter rule enabled.) This seems to indicate that the Untangle server is not able to keep up with the encrypted network traffic.
The Untangle server is running Web Filter Lite, Virus Blocker Lite, Application Control Lite, Captive Portal, Firewall, Intrusion Prevention, and Ad Blocker. AFAIK, Web Filter Lite does not inspect SSL (encrypted) traffic.
Do you think that my conclusion that the Untangle server cannot keep up with the encrypted traffic is what's causing the problems?
Is there something about this configuration (or the Adobe Connect traffic) that puts an unusually large load on the Untangle server? Is there anything that I can do (short of bypassing all port 443 traffic) to reduce the load?
Is an Atom Dual-core 1.8 GHz CPU no longer sufficient for a very small network?
I am having problems when connecting to Adobe Connect web conferencing, used for online training. It will connect and I get audio for 3 to 4 seconds and then freezes, reporting that the connection has poor performance. The poor performance seem to be high latency. (Nothing else significant was happening on the network when these problems occurred.)
Adobe Connect uses HTTP on port 80 and meeting audio and video streams using RTMP on port 1935. If it cannot connect on port 1935, it will use tunneling (RTMPT) on port 80 or 443. The host of the online training forced the meeting to use RTMPT on port 443, which is known to put more of a load on the network. For more on the ports used, see http://helpx.adobe.com/adobe-connect...y-connect.html.
I added a network bypass rules for RTMP (port 135) over TCP and can connect for about a minute before getting disconnected. This supports my theory that the Untangle server is not able to keep up--it works for a while and then gets too far behind. I added a network bypass rule for port 443 over TCP and was able to stay connected. (Of course, I do not want to leave the latter rule enabled.) This seems to indicate that the Untangle server is not able to keep up with the encrypted network traffic.
The Untangle server is running Web Filter Lite, Virus Blocker Lite, Application Control Lite, Captive Portal, Firewall, Intrusion Prevention, and Ad Blocker. AFAIK, Web Filter Lite does not inspect SSL (encrypted) traffic.
Do you think that my conclusion that the Untangle server cannot keep up with the encrypted traffic is what's causing the problems?
Is there something about this configuration (or the Adobe Connect traffic) that puts an unusually large load on the Untangle server? Is there anything that I can do (short of bypassing all port 443 traffic) to reduce the load?
Is an Atom Dual-core 1.8 GHz CPU no longer sufficient for a very small network?
