Web Admin and shell becomes unresponsive when…



  • Hey folks,

    On my LAN, I have an OpenVPN server (running on a seperate machine) connected to an openvpn client which is remote.

    When doing heavy transfers between openvpn server and client, the pfsense webadmin and shell becomes unresponsive (to anyone trying to access it).

    Any ideas why? This is the first time I've come accross this problem.

    I have checked "Disable firewall for traffic on the same interface" and I'm also using a static route

    The firewall is running a VIA EPIA 1GH 512MB RAM

    My inital thoughts are that large traffic (approx 3Mbps) via a static route causes this to happen

    Cheers


  • Rebel Alliance Developer Netgate

    You might try to enable Polling under System > Advanced.

    Here is the description under the option:

    Device polling is a technique that lets the system periodically poll network devices for new data instead of relying on interrupts. This prevents your webGUI, SSH, etc. from being inaccessible due to interrupt floods when under extreme load. Generally this is not recommended. Not all NICs support polling; see the pfSense homepage for a list of supported cards.

    Your system could be reaching the limit of what it can handle in terms of interrupts.



  • Hi jimp,

    Yes, it sounds like an interrupt overload issue. I tried enabling that but it made no difference (Do I need to reboot?)

    I'm not sure if my NIC support it. The one used for the LAN port it an Intel PRO 100

    What should I do? Are there any network cards that will fix this prob for sure?

    Is my system under powered? If so, what specs do you suggest? I always thought that my firewall was overkill considering a cheapy Linksys box runs at 214Mhz


  • Rebel Alliance Developer Netgate

    I think you may need to reboot, but I don't know for certain.

    Usually those Intel cards are pretty good, some of the best out there.

    As for the specs, I'm not familiar with any of the systems based on VIA CPUs, so I can't really say.



  • Rather than just speculate why not take some measurements.

    The shell command vmstat -i will display interrupt counts and rates. You might have high interrupt rates but it might not be your NICs.

    You don't mention how much traffic you are attempting to push through the pfSense box. If you are attempting to do disk-to-disk backups over the VPN then you are likely to have a much heaver load on the pfSense box if you have a 100Mbps channel to the remote end of the VPN than if you have a 256kbps channel.

    The shell command systat -vmstat is useful for displaying a range of useful recent system statistics and the top can be useful for identifying processes which are heavy CPU users.

    My pfSense box has a 800MHz C3 CPU. It has 4 NICs and the ADSL modem usually reports a download speed of 5Mbps to 6Mbps. The web GUI at times seems fairly unresponsive but I don't recall noticing the shell unresponsive on the console.



  • Hi wallabybob,

    That's great advise.

    After enabling polling and rebooting, my problem has seemed to go away.

    I'm not entirly sure if polling did anything to help it - it may have just been the reboot! But if the problem comes back I'll be sure to refer here to quantify the interrupts generated.

    Just FYI, I was trying to do a samba (CIFS) transfer at the time over an openvpn connection (The openvpn server being seperate from the pfsense box) to a remote openvpn client in another country connected via a DSL connection (8Mbps down and 832kbps up as pfsense sees it).

    Before the reboot, pfsense GUI and shell access would be non-exsistant after about 2Mbps or transfers down from the remote server. After the reboot, I can hit 6Mbps (which is the max that this openvpn connection can reach for some unknown reason) without any problems.

    The speed measurements are from pfsense's traffic graph. Before the reboot, I knew that pfsense would become unresponsive at around 2Mbps as that's when the graph would stop working..

    Cheers

    JT


Log in to reply