Slow GUI when viewing through firewall NAT

Customer support forums for Atomic Protector (formerly Atomic Secured Linux). There is no such thing as a bad question here as long as it pertains to using Atomic Protector. Newbies feel free to get help getting started or asking questions that may be obvious. Regular users are asked to be gentle. :-)
igroup
New Forum User
New Forum User
Posts: 1
Joined: Mon Jan 18, 2010 3:43 am

Slow GUI when viewing through firewall NAT

Unread post by igroup »

Hi everyone, I hope you can shed some light for me on a problem I have with the Tortix UI:

The ASL installation runs on web servers using RFC1918 IP addresses, e.g. 192.168.30.10. The servers sit behind a pfSense firewall, which is used to NAT the private IP to a public IP on a one-to-one basis, i.e. 192.168.30.10 maps to xx.xx.xx.10 and vice versa.

If I access the Tortix UI from a Windows server sitting behind the same firewall as the ASL-secured servers, I can load up the ASL GUI very fast and use it with no issue at all.

If I access the Tortix UI from my laptop, over the Internet, and use the server's public IP (the xx.xx.xx.10 IP referred to earlier), it takes up to 5 minutes for the web interface (GUI) to load, and it is significantly slower than when I access it from behind the firewall.

I've run iftop on the server via SSH while loading the Tortix GUI in my browser (all from my laptop), and I see lots of connections on the Tortix port (30000) on the server, but running between the server's real IP (192.168.30.10) and it's public (NAT'ted) IP, xx.xx.xx.10. These connections only appear when I access the Tortix GUI from the Internet side and go through the firewall.

My reasoning is that the request sent to xx.xx.xx.10 is translated to 192.168.30.10 by the firewall and sent on to the Tortix server, but instead of just replying to the response, Tortix somehow picks up on the xx.xx.xx.10 request and tries to serve the response from that IP address.

We run e-com sites for major corporates on these servers, using Apache (just like the Tortix UI) and do not see this behavior with the e-com sites.

The only solution I could think of is to change the bind address in the Tortix httpd.conf file to the 192.168.30.10 IP address, but that would not be the best solution as I would need to reinstate the change after an upgrade/update to Tortix and I would lose the portability of ASL - if I changed the server's IP address for some reason, I would again need to change the Bind address in Tortix's httpd.conf.

Does anyone have an explanation and solution to this problem?

Thanks a stack in advance.

Regards,

Arie.
Post Reply