Help troubleshoot pfSense slow speed



  • Started with pfSense1 typical configuration of ISP wan and lan subnet 192.168.1.0/24. All working as expected.

    Add pfSense2 with wan port plugged to switch on lan subnet 192.168.1.0/24.
    pfSense2 lan port is plugged into switch on lan subnet 192.168.2.0/24. Computers can max out internet connection going through 2 pfSense gateways. Trouble is when computers on 192.168.2.0/24 contacting 192.168.1.0/24 computers through pfSense2, the speed is slower than the internet connection. Staying on the same subnet yield speeds 20 time faster.

    I am guessing that the slowdown has something to do with NAT and mtu 4000 on computers and mtu 1500 on pfSense2. What do I do to speed up private network through pfSense2?


  • LAYER 8 Netgate

    So you're intentionally running jumbo frames on that segment?  Did you try setting pfSense 2's WAN interface MTU to 4000?  You probably need to do the same on pfSense 1's LAN.

    There's also a problem with setting MTU in 2.2.  Not sure if it'll apply to you: https://redmine.pfsense.org/issues/4397



  • Thank you for your input to help resolve my slow speed issues.

    I did try setting pfSense2 wan to 4000 and pfSense lan to 4000 in the webgui. This interrupted many network connections. I decided to reset them to default and restart. Next, I changed the computers on both segments to 1500 which did not help improve speed. Any ideas?


  • LAYER 8 Netgate

    Doublecheck everything.  You start messing around with MTUs and you're sort of on your own.  Impossible to know.

    Taking interface errors anywhere?  Hosts?  Switch ports? pfSense?



  • @gjaltemba - Packet fragmentation is layer 3, MTU sizes are layer 2.  The MTU settings on each interface need to match on the same layer 2 network.  The slowdowns you're seeing are computers attempting to defragment/fragment the packets because the MTU sizes aren't matching on the same layer 2 network.

    I doubt the packet sizes were ever large enough to matter when going to the Internet, especially if they were all download based.  You'd be getting 1500 MTU max from upstream.  If it were the other way around where the responses were larger, you'd see the problem.

    Unless you're doing something that requires it, stay away from adjusting MTU sizes.  The only uses I've had for jumbo frames are storage related, e.g. iSCSI, SMB3, NFS, etc.  For the most part, those use cases I mentioned should not be routed, multi-home anything that needs to use it.

    Started with pfSense1 typical configuration of ISP wan and lan subnet 192.168.1.0/24. All working as expected.

    Add pfSense2 with wan port plugged to switch on lan subnet 192.168.1.0/24.
    pfSense2 lan port is plugged into switch on lan subnet 192.168.2.0/24. Computers can max out internet connection going through 2 pfSense gateways. Trouble is when computers on 192.168.2.0/24 contacting 192.168.1.0/24 computers through pfSense2, the speed is slower than the internet connection. Staying on the same subnet yield speeds 20 time faster.

    I am guessing that the slowdown has something to do with NAT and mtu 4000 on computers and mtu 1500 on pfSense2. What do I do to speed up private network through pfSense2?

    WAN on pfSense1, leave at default, I doubt your ISP is changing from the default 1500.  LAN on pfSense1 and WAN on pfSense2, MTU sizes should match.  LAN on pfSense2 MTU size should be for that segment.  For example:

    192.168.1.0/24 - 4000 MTU - LAN on pfSense1 and WAN on pfSense2
    192.168.2.0/24 - 1500 MTU - LAN on pfSense2

    If the MTU sizes in my example are reversed of actual just flip them, I was going based off examples in the previous posts.  Also, ALL computers running on a layer 2 segment MUST match the maximum MTU of other interfaces on the same segment.  Including the one you're using to access pfSense.  Keep that in mind when you're making adjustments.



  • Thank you for your input to help optimize my mtu settings. My mtu settings are only experimental. Some settings did cause packet fragmentation and even timeouts.

    In the end, I remembered that the pfsense traffic shaper was given a low speed for the wan port and needed a bump up. Doh!


Log in to reply