Curious problem - ping increase across the board with pfSense

  • evening everyone - first time poster, though I work with pfSense a lot for work I haven't had to deal with a problem like this yet.

    Problem - 30 to 40 MS increase in ping across the board with pfSense in place compared to wndr3700 in place.

    Info for problem -

    WAN connection - 50down / 10up Comcast

    Current Setup : Comcast Modem –> pfsense --> gigswitch/lan --> wired workstation
    Previous Setup: Comcast Modem --> Netgear WNDR3700 --> gigswitch/lan --> wired workstation

    testing platform - comcast modem --> pfsense or WNDR3700 --> gigswitch --> wired workstation

    pfsense hardware 1 - Atom D2550 w/ 4GB ram running 2.0.3 32bit, broadcom gigabit ports
    pfsense hardware 2 - Xeon e3110 w/8GB ram running 2.0.3 64bit, intel gigabit ports (test bed server system I have laying around)

    After working with more robust firewalls like pfSense for my job, i was beginning to feel a bit unsecure at home with your run of the mill off the shelf router/firewall, so I replaced the netgear wndr3700 in 'previous setup' with the pfsense box in 'current setup'.

    the issue now is this - ping times across the board have increased by 30-40MS. I have two different hardware setups and both end up with the same increase in ping over the WNDR3700.
    I can remove the pfsense, put the wndr3700 back in place and the ping goes right back down, again across the board.

    I only have one connection so i'm not using any scheduling, traffic shaping or qos.

    Solutions I've already tried -

    1 - try different hardware - done
    2 - open ports for various games in firewall rules - done
    3 - Static NAT the ports used for various games - done
    4 - check for system resource usage; no problem there, everything low/not near limits - done
    5 - noticed on some older posts that device polling might work, it didn't for me. - done
    6 - Tried the RC for 2.1

    EDIT - not fixed yet, just played various games for a while and noticed worse performance compared to WNDR3700. also added #5 above.
    EDIT2 - tried RC for 2.1 and that didn't help, was desperate to try and keep pfSense in the fold here. Running multiple RDP sessions and logmein sessions this morning for work, I've had to switch back to my WNDR3700 as it seemed that the pfsense box was struggling to keep up with the bandwidth demand. Prior to moving the pfsense box out of the way, I took note of the system utilization - nothing was near pushing system resource limits.
    Edit3 - just noticed that with the WNDR i get a 71.X.X.X address from comcast and on the pfsense I get a 69.X.X.X address. not sure it means anything, but its an interesting difference.

    so, thoughts?

    Thanks in advance for your time!

  • Most probably a driver issue. Run pfSense in ESXi on the same server and see.

  • Thanks Kurian I'll give it a shot and report back!.

  • Just poking around, looking for general tuning tips, and came across the post.

    Any miracle cures?

    Also… the different IP from Comcast is probably due to the different MAC from your devices.  DHCP registrations will usually "reserve" for a MAC for a while (5 days..?) unless the address is needed.  So, if you attach within that time, you get the same IP.  If you are away for 5 days or that address gets used otherwise, it will get recycled.  But... you change to another NIC, you get a different IP.

    Let us know if you figured anything out... I'll post if I do :-)  Cheers...

  • been a while and haven't had a chance to try ESX/VMware or the release of 2.1.  no miracle yet as I haven't put the pfSense back in place to test. I'll have some time over the next few weeks and give things ago.

  • UPDATE -

    I updated the micropc to the latest 32bit release and the issues have disappeared.

    once change I made between the current setup and when I posted this was unblocking private networks on the WAN side as Comcast modems have a private network they use and I wanted to be able to check my modem status on regular basis.

    For clarification - i386 version 2.1.1 pre-release dated 26 mar 1350EDT 2014 has fixed my issues.

Log in to reply