Shaper Wizard generates bogus rules for VoIP
-
@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. -
@ermal:
You need to install a new snapshot where this has been fixed.
A local pfsense patch was missing hence the errors.As I said, it's semi-fixed in the latest snapshot. This error is gone, but the traffic shaper still doesn't work due to 2349. Additionally, this (or another very recent change since rolling back to Wednesday's build fixed it) breaks the PPTP server.
-
For those of us not using vLANs, this seems to have fixed the issue. Thank you very much Ermal!!!
