Bug in traffic shaper's configuration saving corrupts pfsense's tables.
-
Hi, same problem here today, yesterday i setup the traffic shapper and today i have no out traffic, after remove the traffic shapper the net beging work well. PF 2.2.4
-
Having the same issue. Saved traffic shaping for VoIP, everything was great, came back Monday and LAN traffic not going out to WAN. Anyone had any progress?
-
Yup similar issue here as well.
Ill configure the traffic shaper, it'll work for a few days and then it randomly stops working and halts all net traffic until I remove it.
-
You are all referring to the traffic-shaping wizard, yeah?
I have no troubles, but I do not use the wizard.
-
I've experienced the same issue. In my case it appears to only be an issue when WAN is configured using DHCP and the Traffic Shaper is configured using the wizard. To verify the issue, try running this from Diagnostics > Command prompt when the issue is occurring and the pfSense is not passing traffic from internal networks:
Diagnostics > Command prompt > pfctl -f /tmp/rules.debug
$ pfctl -f /tmp/rules.debug
bandwidth for qInternet higher than interface
/tmp/rules.debug:63: errors in queue definition
parent qInternet not found for qACK
/tmp/rules.debug:64: errors in queue definition
parent qInternet not found for qP2P
/tmp/rules.debug:65: errors in queue definition
parent qInternet not found for qVoIP
/tmp/rules.debug:66: errors in queue definition
parent qInternet not found for qOthersHigh
/tmp/rules.debug:67: errors in queue definition
parent qInternet not found for qOthersLow
/tmp/rules.debug:68: errors in queue definition
bandwidth for qInternet higher than interface
/tmp/rules.debug:73: errors in queue definition
parent qInternet not found for qACK
/tmp/rules.debug:74: errors in queue definition
parent qInternet not found for qP2P
/tmp/rules.debug:75: errors in queue definition
parent qInternet not found for qVoIP
/tmp/rules.debug:76: errors in queue definition
parent qInternet not found for qOthersHigh
/tmp/rules.debug:77: errors in queue definition
parent qInternet not found for qOthersLow
/tmp/rules.debug:78: errors in queue definition
pfctl: Syntax error in config file: pf rules not loadedThis prevents the rules from loading correctly, thus preventing traffic from being correctly NAT'd. This is why removing the shaper resolves the issue. Can anyone else confirm that they see the same errors and also please let us know how you configure your WAN interface (DHCP, static, etc).
The config was built with the WAN interface having a 1Gbps connection and the bandwidth of the uplink configured as 100 Mbps. The interface speed has not changed, so it would seem odd that such an error would be reported since 100 Mbps < 1Gbps.
-
parent qInternet not found for qVoIP
The WAN doesn't have a qInternet. Whatever in the wizzard is setting up the queues should just remove the reference to qInternet and that should fix it.
-
I've actually narrowed down the issue on my side. It has nothing to do with the WAN being configured DHCP - that was just a coincidence. The issue is that if the traffic shaper was configured with a set of interfaces and any one of them is down, the rule set breaks. I believe this is because a down interface is assigned 0 bandwidth and thus the rule exceeds the available bandwidth for the interface (as per the error message). This may make sense in theory, but in practice segments of a network could be down for a variety of reasons and thus booting into this bad state seems like not the desired behavior (and especially losing all inbound filtering on WAN and leaving it in a fully open state). As such, I don't believe my issue (which is deterministic in nature and due to an interface being down) is the same as the ones described/reported by others, which seems to be more like:
https://redmine.pfsense.org/issues/4856
For anyone that does encounter the issue, I'd recommend trying to run the pfctl command I posted above to capture the error output (if any), as it'd likely be useful to the pfSense team in resolving the issue.
-
I had the weirdest this today. All of a sudden at 12:40 this afternoon, our internet link went down. wasn't our supplier. the traffic shaper was running perfectly for over a week. the weird part was that no traffic would pass, nothing hit the firewall rules, however users VPN was working fine, ie they could get logged in. After rebooting a couple of times I saw these weird entries in the log.
Oct 21 13:31:02 php: rc.bootup: The command '/usr/bin/nice -n20 /usr/local/bin/rrdtool update /var/db/rrd/lan-queues.rrd -t qLink:qInternet:qACK:qP2P:qVoIP N:U:U:U:U:U' returned exit code '1', the output was 'ERROR: tmplt contains more DS definitions than RRD'
Oct 21 13:31:02 php: rc.bootup: The command '/usr/bin/nice -n20 /usr/local/bin/rrdtool update /var/db/rrd/lan-queuedrops.rrd -t qLink:qInternet:qACK:qP2P:qVoIP N:U:U:U:U:U' returned exit code '1', the output was 'ERROR: tmplt contains more DS definitions than RRD'
Oct 21 13:31:02 php: rc.bootup: The command '/usr/bin/nice -n20 /usr/local/bin/rrdtool update /var/db/rrd/ipsec-packets.rrd N:U:U:U:U:U:U:U:U' returned exit code '1', the output was 'ERROR: expected 4 data source readings (got 8) from N:U:U:U:U:U:U:U:U'I saw the words lan-queues and thought traffic shaper maybe? lets try turning it off. Bang all traffic starts flowing again. I am wondering what happened and I am not turning it on again.
Frank
-
Those are graphs that pfSense records to internally. Although they may be a symptom of the same root cause, I don't think anything to do with RRD would be the cause itself. Did you happen to try running the pfctl command?
Diagnostics > Command Prompt > pfctl -f /tmp/rules.debug
When you have an issue with traffic flow, try running that command before clearing the shaper config.
There is a known issue with HFSC (and maybe other schedulers) where the Wizard will create a configuration that has a blank value for the root queue of each non-WAN interface and the "bandwidth" is automatically determined, presumably based on the link speed. Unfortunately, if the interface is down, the link speed (I believe) is 0, thus resulting in an error (which you would see with the pfctl command) about a sub-queue specifying bandwidth greater than the interface.
See https://redmine.pfsense.org/issues/5325 for reference.
-
Yes, however at the time my entire network had stopped working, prime time and all. First and foremost that I needed to get the link back up. I intend to revisit this again, I have another pfsense router coming in so I will be able to do some testing. We are a software development company and Internet is important lol. I am going to look at the blank value when I redo this.