pfSense Plus version 22.01 and pfSense CE version 2.6.0 Software are Now Available!
-
yes. but not on the VLAN which has the traffic shaping rate limiter.
the captive portal VLAN has rate limited in the captive portal page itself and which doesn't require firewall rules and which works correctly. The VLAN which has no captive portal but instead uses traffic shaping firewall rules to rate limit blocks clients from accessing the internet.
-
ok...I could get around the bug by enabling captive portal on the VLAN that doesn't have CP enabled and use the rate limiter in the captive portal config page and disabled the rate limiter in the firewall. All works well and actually prefer it this way as it is consistent with my other VLANs which use the CP.
Since I don't want the login page to appear for this VLAN I configured to allow 100 pass through credits and 1 hour to restore the credits. Seems to work just as well.
-
Yeah, that would do it.
The bug is as described there. If you have the captive portal enabled on any interface then ipfw is active. And if ipfw is active then traffic sent to dummynet pipes (Limiters) by pf will fail. So to use Limiters outside of captive portal, captive portal must be disabled entirely on all interfaces.
Steve
-
Another problem discovered with my 2.6.0 upgrade. I have configured my ppp connection to reset each day at 3am. I noticed in the logs from 3am - 4am every minute the ppp will reset itself over and over again 59 times then stop at 4am and remain stable until the next ppp reset at 3am the following day. It repeats this connect/disconnect pattern everyday for exactly 1 hour.
-
Hmm, interesting. Does it connect successfully, repeatedly during that time?
-
yes. I get 59 new IP addresses over the course of 1 hour.
I have disabled the option to reset the ppp connection for now.
-
@papdee said in pfSense Plus version 22.01 and pfSense CE version 2.6.0 Software are Now Available!:
yes. I get 59 new IP addresses over the course of 1 hour.
I have disabled the option to reset the ppp connection for now.
What is your selection for the Periodic Reset option? It sounds like you have a bad custom option set. Daily at 3am would be Hour:
3, Minute:0. If you put*in minute it would run at every minute during 3:00am-3:59am. -
OK, I need to force it to "0" . It defaults to * so I missed that.
-
the pppoe reset option will ignore all user input and enter * into CRON for minutes. The only to get around this is to manually edit the CRON job which I don't want to do.
Another bug came up with the captive portal. If you click on Enable custom page and upload your own custom page then click save then go back and click live view it will always show the default netgate page.
Another bug with captive portal: if custom page is already clicked to enable and you try to unclick enable custom page and then try to save it doesn't unclick enable custom page. Once you have clicked custom page it us always enabled.
-
Looks like it just doesn't like
0. If you enter a non-zero value such as1or30it takes it. But if you enter0then on save it changes to*. -
I created a Redmine issue to have the issue corrected:
https://redmine.pfsense.org/issues/13307 -
not sure this is coincident with the new release but after a ISP outage I found that dhcp service stopped handing out default gateway assignments. I had to go to each one and give the default default gateway value even though it wasn't required before.
-
@nrf said in pfSense Plus version 22.01 and pfSense CE version 2.6.0 Software are Now Available!:
not sure this is coincident with the new release but after a ISP outage I found that dhcp service stopped handing out default gateway assignments. I had to go to each one and give the default default gateway value even though it wasn't required before.
That is unrelated. That can happen if your upstream/WAN doesn't provide you with a gateway via DHCP. Some have also seen it if DHCP starts while a WAN is down. We're looking into ways to improve that behavior.
-
@jimp quick response!
ok, started while wan was down would explain.
but 192.168.xx.1 can be a perfectly good default gateway ip whether there is a wan or not so kind of curious behavior. now that I have populated the default default I won't be bothered by it again but it cost me in down time after ISP was restored. it makes the advertised behavior on that page no longer a certainty, maybe add 'might' or 'should' there?
-
This post is deleted! -
R rcoleman-netgate unpinned this topic on
