Shaper Wizard generates bogus rules for VoIP
-
Using today's snapshot, I'm finding that the VoIP rules generated by the shaper throw a syntax error when loaded. Using multi-wan, single lan. I found that both the "imported" rules from my 11/2011 snapshot failed as did new ones. Setting just the checkbox and selecting "vonage" generates errors, as does specifying my ata IP by IP or alias. I don't have the exact error at the moment - the ajax refresh on the rules reload does a good job of preventing copying. And at this very moment I seem to have lost web access to the box.
I'll add details when I figure out how to get back in… :)
OK, after forcefully killing lighty and the php fcgi processes a few times I got back in (option 11 was doing nothing - ssl handshake was OK, but no data was ever returned).
Here's the failed rules:
using an alias callled "ata": Apr 4 21:49:26 php: : The command '/sbin/pfctl -o basic -f /tmp/rules.debug' returned exit code '1', the output was '/tmp/rules.debug:244: syntax error pfctl: Syntax error in config file: pf rules not loaded' Apr 4 21:49:26 php: : New alert found: There were error(s) loading the rules: /tmp/rules.debug:244: syntax error pfctl: Syntax error in config file: pf rules not loaded - The line in question reads [244]: match proto udp from $ata to any queue (qVoIP) label "USER_RULE: VOIP Adapter" Apr 4 21:49:26 php: : There were error(s) loading the rules: /tmp/rules.debug:244: syntax error pfctl: Syntax error in config file: pf rules not loaded - The line in question reads [244]: match proto udp from $ata to any queue (qVoIP) label "USER_RULE: VOIP Adapter" using an explicit IP: Apr 4 21:51:53 php: : The command '/sbin/pfctl -o basic -f /tmp/rules.debug' returned exit code '1', the output was '/tmp/rules.debug:244: syntax error pfctl: Syntax error in config file: pf rules not loaded' Apr 4 21:51:53 php: : New alert found: There were error(s) loading the rules: /tmp/rules.debug:244: syntax error pfctl: Syntax error in config file: pf rules not loaded - The line in question reads [244]: match proto udp from 10.3.2.19 to any queue (qVoIP) label "USER_RULE: VOIP Adapter" Apr 4 21:51:53 php: : There were error(s) loading the rules: /tmp/rules.debug:244: syntax error pfctl: Syntax error in config file: pf rules not loaded - The line in question reads [244]: match proto udp from 10.3.2.19 to any queue (qVoIP) label "USER_RULE: VOIP Adapter" not specifying an IP: Apr 4 21:54:25 php: : The command '/sbin/pfctl -o basic -f /tmp/rules.debug' returned exit code '1', the output was '/tmp/rules.debug:244: syntax error pfctl: Syntax error in config file: pf rules not loaded' Apr 4 21:54:25 php: : New alert found: There were error(s) loading the rules: /tmp/rules.debug:244: syntax error pfctl: Syntax error in config file: pf rules not loaded - The line in question reads [244]: match on { xl0 dc0 } proto udp from any to any port 5059 >< 5070 queue (qVoIP) label "USER_RULE: m_voip Asterisk outbound" Apr 4 21:54:25 php: : There were error(s) loading the rules: /tmp/rules.debug:244: syntax error pfctl: Syntax error in config file: pf rules not loaded - The line in question reads [244]: match on { xl0 dc0 } proto udp from any to any port 5059 >< 5070 queue (qVoIP) label "USER_RULE: m_voip Asterisk outbound" -
can you attach the full /tmp/rules.debug file
-
@cmb:
can you attach the full /tmp/rules.debug file
Sure, I'll re-run the wizard and grab the file as soon as I can take things down for a few minutes.
Should I PM the file or should I just manually scrub out external IPs?
-
Here is a (hopefully) sanitized rules.debug. This is with the generic "asterisk/vonage" VoIP option and no device IP specified.
-
After doing full update from 2.1-DEVELOPMENT (i386)
built on Fri Nov 25 14:30:42 EST 2011
FreeBSD 8.1-RELEASE-p6
to pfSense-Full-Update-2.1-DEVELOPMENT-i386-20120405-0518.tgz with traffic shaper active, I have the same syntax problem for all floating rules, that causes NAT to stop working at all. Removing shaper and custom floating rules is fixing the problem, but after sometime pfsense (or PHP) randomly corrupts own .inc files, writing about "error at line bla-bla… in interfaces.inc (for example)" (sorry I can't replicate that now, may be later). Every time I have to manually restore backup under 13-th menu option in console and all is working fine until I try to upgrade again and change the floating rules. I have the same problems with an older version pfSense-Full-Update-2.1-DEVELOPMENT-i386-20120226-0110.tgz -
upgraded today to latest snapshot, internet connection was established but rules didn't get loaded.
i removed shaper rules and everythings works fine again.
There were error(s) loading the rules: /tmp/rules.debug:158: syntax errorpfctl: Syntax error in config file: pf rules not loaded - The line in question reads [158]: match on { pppoe0 } proto udp from any to any port 500 queue (qOthersHigh) label "USER_RULE: m_Other IPSEC outbound" ... -
This looks to be the same issue I started this thread about: http://forum.pfsense.org/index.php/topic,47890.0.html
-
https://redmine.pfsense.org/issues/2373
-
Thanks for the redmine link … I have tried to manually edit the rules and I cannot find the syntax error. Still looking. Did we change versions of pf or pfctl recently?
-
Any update on this? I'm trying to get pfSense running on a box with a Realtek 8111E onboard NIC, which needs FreeBSD 8.3 to function properly (2.0.1 doesn't even see it). Without traffic shaping, it's a no go. Yup, I know, it's pre-beta and "it's done when it's done" - but if there's any testing that needs done or anything I can do to help (I'm not a programmer unfortunately), let me know :)
-
No update, I am trying every build comes out! No difference. No moves
-
You can watch the Redmine link and https://github.com/bsdperimeter/pfsense/commits/master for any updates to traffic shaper code. Once you see an update, wait till the next day (or build your own iso) or so and then update.
-
Thanks pod, though I knew that part I guess what I'm saying is, this is a major portion of pfSense, and while I'm not a programmer, if there's anything in terms of testing or anything to push this fix along, toss me a message :)
-
You can watch the Redmine link and https://github.com/bsdperimeter/pfsense/commits/master for any updates to traffic shaper code.
It's a kernel issue, you'll see it in https://github.com/bsdperimeter/pfsense-tools/commits/master , not there. But the ticket will be updated in redmine. It may be some time still, Ermal who does all our kernel work is buried in customer development projects at the moment and what pays our bills has to come first. Those are wrapping up, hopefully after BSDCan he can knock out the remaining major kernel-related issues in 2.1/FreeBSD 8.3.
-
Thanks for the info and the link :) I got myself into this mess myself because I counted on 2.1 coming out by the end of April when there's no promises or guarantees in this world :D Thanks for all the great work you guys do. I tried a bunch of other solutions and found nothing I liked as well. Sure, part of that maybe familiarity, but still… great job!
-
@cmb:
It may be some time still, Ermal who does all our kernel work is buried in customer development projects at the moment and what pays our bills has to come first. Those are wrapping up, hopefully after BSDCan he can knock out the remaining major kernel-related issues in 2.1/FreeBSD 8.3.
That's great news, because I had noticed the slowdown of commits in the 2.1 tree at git for several weeks now and wasn't quite sure what was going on …
-
Thanks for the info and the link :) I got myself into this mess myself because I counted on 2.1 coming out by the end of April when there's no promises or guarantees in this world :D
Unfortunately FreeBSD and many other things aren't as IPv6-ready as we'd hoped for a number of the things we rely upon so we've had to do a lot more than just slap a GUI on things (though that's long since become the norm).
That's great news, because I had noticed the slowdown of commits in the 2.1 tree at git for several weeks now and wasn't quite sure what was going on …
That's not true at all, there hasn't been any slow down in commits.
https://github.com/bsdperimeter/pfsense/graphs/commit-activity -
Well, I see Ermal's back to working on pfSense today, so hopefully that's a sign this'll get addressed sooner than later :) Thanks for the wonderful work pfSense team!
-
This is semi-fixed now. Traffic shaping still doesn't work due to 2349, and the patch changes to fix this seem to have broke the PPTP server
-
You need to install a new snapshot where this has been fixed.
A local pfsense patch was missing hence the errors.
