Outbound traffic stalling
-
Did some more thorough testing.
Account1 = the account I have been testing with the whole time in this thread.
Account2 = another account with same ISP and I have been using this account for about 4-5 years in this house without an issue (with a NetGear Modem)
ADSL1 modem = an old Alcatel Speed Touch modem that does not even have PPPoE build in used. About 10 years old.
ADSL2 modem = a TP-Link TD-8840At my new house I have been doing the testing above with Account1. I then did another test over the weekend where I used this ADSL1 modem. It is was in bridge mode and the pfsense box WAN in PPPoE.
Same issue occoured. Uploads hit about 3MB and then stalled. (have packet captures.)Did some in another house with a different account (same ISP).
Summary of tests and results from me taking my firewall and 2 different modems to this other house.
- ADSL1 modem used with Account1 and my pfsense firewall in PPPoE. Uploads stalled.
- ADSL1 modem used with Account2 and my pfsense firewall in PPPoE. Uploads stalled.
- ADSL2 modem used with Account1 and my pfsense firewall in PPPoE. Uploads stalled.
- ADSL2 modem used with Account2 and my pfsense firewall in PPPoE. Uploads stalled.
- ADSL2 modem used with Account1 in PPPoE mode so pfsense firewall in STATIC IPv4 on the WAN resulted in uploads working but the same unusable state for the connection. DNS queries failed.
- ADSL2 modem used with Account2 in PPPoE mode so pfsense firewall in STATIC IPv4 on the WAN resulted in uploads working but the same unusable state for the connection. DNS queries failed.
So it seems the stalling issue only has the pfsense box as its common item across all the testing.
And it also seems it is not a QoS issue on the ISP side as I used a different account (that does not have a VoIP plan) on a different phone line/residence. So this issue could be separate and simply a modem issue??I have packet captures for some of these tests.
-
@cmb:
Curious, is this a case where hardware firewalls/routers do some slight trafic shaping under the covers while pfsense truly does what you tell it and nothing without you setting it up and this there needs to be a baseline traffic shaping setup to mitigate this?
No. The "hardware firewalls/routers" are actually no different, they're no more "hardware" than what you're running now, they're a piece of hardware running an OS that does all the work, effectively identical, just different software and hardware. Without shaping, the limits and queuing on your connection are entirely upstream, with any router or firewall.
I guess what I meant was more do these commercial routers/modems have some baseline shaping rules that pfsense does not as it allows you to totally control the traffic flow?
-
I went through the wizard for setting up Traffic Shaping and just used PRIQ as it is a simple setup and I am new to pfSense.
This solved the issue with uploads destroying my net connection and making all but useless.
(A side note, I found I had to set the UP and DOWN bandwidth to less than what the modem was precisely reporting as the speed it had connected to the DSLAM at)So maybe this same traffic shaping will allow this install to be in PPPoE mode with this modem.
I might give it one more go this weekend.
-
Has there been any progress on this issue? We seem to be affected by the same bug.
Our setup differs from the one described by DaveQB, though. We have pfSense configured with three interfaces (all bce). It is also the default gateway for all machines in the LAN. Routes are configured on the box for traffic to other branch offices. All checksum offloading has been disabled, but it didn't help. pfSense is configured for bypassing traffic on the same interface.
When I try to transfer a file using scp from office A to office B using pfSense as default gateway the transfer will stall leaving an incomplete file on the receiving end which is exactly 48k. Interrupting the stalled transfer and immediately trying again will succeed.
Circumventing pfSense by adding a route on office A's server to office B's LAN using the VPN router directly (which is also in the LAN) works without any problem.
I have been tinkering with kernel MTU parameters, but to no avail.
We are running 2.0-RC1 (amd64) built on Sat Feb 26 18:07:23 EST 2011. This is an in place upgrade from 1.2.3-RELEASE built on Sun Dec 6 23:21:36 EST 2009.
-
Has there been any progress on this issue? We seem to be affected by the same bug.
Our setup differs from the one described by DaveQB, though. We have pfSense configured with three interfaces (all bce). It is also the default gateway for all machines in the LAN. Routes are configured on the box for traffic to other branch offices. All checksum offloading has been disabled, but it didn't help. pfSense is configured for bypassing traffic on the same interface.
When I try to transfer a file using scp from office A to office B using pfSense as default gateway the transfer will stall leaving an incomplete file on the receiving end which is exactly 48k. Interrupting the stalled transfer and immediately trying again will succeed.
Circumventing pfSense by adding a route on office A's server to office B's LAN using the VPN router directly (which is also in the LAN) works without any problem.
I have been tinkering with kernel MTU parameters, but to no avail.
We are running 2.0-RC1 (amd64) built on Sat Feb 26 18:07:23 EST 2011. This is an in place upgrade from 1.2.3-RELEASE built on Sun Dec 6 23:21:36 EST 2009.
I haven't done any more. Mine is working great if I have pfsense in DHCP client mode (from the modem) rather than PPPoE mode (and modem in bridge mode) AND basic shaping setup. If either of these 2 things are not true, then my connection is hosed.
2.0-RC1 (i386)
built on Mon Feb 28 18:12:00 EST 2011