Upgrade 2.5.2 to 2.6.0, upgrade success, Limiters not passing
-
@pooperman Hmm, interesting. What is the default route after a reboot before you reapply the gateway? Does the VPN come up correctly?
Steve
-
@stephenw10
How I can see default route?
VPN come up correctly after reboot. Its receive ip address and marks green on dashboard.
Another thing I noticed is that after rebooting the default gateway has no globe icon. After reapply gateways settings by hand it appears.
Also its possible to restart VPN connection instead of reapply gateways settings. After that internet is also has up. -
Diagnostic --> Routes
-
It sounds like it might be trying to apply the default route before gateway is valid for some reason.
Have you editing the OpenVPN gateway at all? To set a different monitoring IP for example.
Steve
-
@bingo600
Interesting. It is no default route at all after reboot.@stephenw10
No. I did not edit OpenVPN gateway. -
Try editing and saving the OpenVPN gateway without making any changes. It will create the gateway entry in the config which will mean it's present before it connects. Though the route will still be invalid.
Steve
-
@stephenw10
No. There is no effect. Still have not internet connection after reboot. -
@steveits said in upgrade 2.5.2 to 2.6.0, upgrade success, no internet conection:
That should just remove the rule on WAN to block inbound traffic from bogons.
That's also not something I would want anyone else to do. Especially if you were behind a CGNAT...
-
@pooperman Then I would check the boot and routing log for errors.
You might also check the OpenVPN log since that can often try to set a new default route when it connects.
Steve
-
<dnshaper> <queue> <name>PublicWLANIn</name> <number>1</number> <qlimit></qlimit> <plr></plr> <description></description> <bandwidth> <item> <bw>15</bw> <burst></burst> <bwscale>Mb</bwscale> <bwsched>none</bwsched> </item> </bandwidth> <enabled>on</enabled> <buckets></buckets> <mask>none</mask> <maskbits></maskbits> <maskbitsv6></maskbitsv6> <delay>0</delay> <sched>fifo</sched> <aqm>droptail</aqm> <ecn></ecn> </queue> <queue> <name>PublicWLANOut</name> <number>2</number> <qlimit></qlimit> <plr></plr> <description></description> <bandwidth> <item> <bw>30</bw> <burst></burst> <bwscale>Mb</bwscale> <bwsched>none</bwsched> </item> </bandwidth> <enabled>on</enabled> <buckets></buckets> <mask>none</mask> <maskbits></maskbits> <maskbitsv6></maskbitsv6> <delay>0</delay> <sched>fifo</sched> <aqm>droptail</aqm> <ecn></ecn> </queue> <queue> <name>CHFreeWiFiIn</name> <number>3</number> <qlimit></qlimit> <plr></plr> <description></description> <bandwidth> <item> <bw>5</bw> <burst></burst> <bwscale>Mb</bwscale> <bwsched>none</bwsched> </item> </bandwidth> <enabled>on</enabled> <buckets></buckets> <mask>none</mask> <maskbits></maskbits> <maskbitsv6></maskbitsv6> <delay>0</delay> <sched>wf2q+</sched> <aqm>droptail</aqm> <ecn></ecn> </queue> <queue> <name>CHFreeWiFiOut</name> <number>4</number> <qlimit></qlimit> <plr></plr> <description></description> <bandwidth> <item> <bw>15</bw> <burst></burst> <bwscale>Mb</bwscale> <bwsched>none</bwsched> </item> </bandwidth> <enabled>on</enabled> <buckets></buckets> <mask>none</mask> <maskbits></maskbits> <maskbitsv6></maskbitsv6> <delay>0</delay> <sched>wf2q+</sched> <aqm>droptail</aqm> <ecn></ecn> </queue> </dnshaper>
-
So all traffic using those Limiter pipes is failing or just the FreeWIFI?
-
@tohil said in upgrade 2.5.2 to 2.6.0, upgrade success, no internet conection:
Same here in my environment. Updated from 2.5.2 to 22.1
I have two networks with limiters on rules for these interfaces.all traffic which should pass these rules are not working until I remove the In / Out pipe limiters.
I'm having the same issue. The limiters have been working fine with v2.5.2.
I even tried a clean install of this v2.6.0 on different devices traffic passes fine but when I activate any rule with In/Out pipes define, traffic stops flowing and there's no internet access.I reinstalled v2.5.2 and everything works fine and limiters working as before.
I strongly believe this is a bug with the Limiters feature and it's to some degree similar to this one.
-
@stephenw10 all
-
And no unusual config there, just the default settings?
-
You see anything in Diag > Limiter Info when it's failing?
Works as expected and shows as expected for me in a simple test case:
Limiters: 00001: 50.000 Mbit/s 0 ms burst 0 q131073 50 sl. 0 flows (1 buckets) sched 65537 weight 0 lmax 0 pri 0 droptail sched 65537 type FIFO flags 0x0 0 buckets 1 active BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 ip 0.0.0.0/0 0.0.0.0/0 34 1768 0 0 0 00002: 50.000 Mbit/s 0 ms burst 0 q131074 50 sl. 0 flows (1 buckets) sched 65538 weight 0 lmax 0 pri 0 droptail sched 65538 type FIFO flags 0x0 0 buckets 1 active 0 ip 0.0.0.0/0 0.0.0.0/0 71499 107245606 43 64500 0 Schedulers: 00001: 50.000 Mbit/s 0 ms burst 0 sched 1 type WF2Q+ flags 0x0 0 buckets 0 active 00002: 50.000 Mbit/s 0 ms burst 0 sched 2 type WF2Q+ flags 0x0 0 buckets 0 active
-
I cannot post, because akismet anti-spam engine...
-
Seems like its doing some unknown packet transfer bug on a idle connection.
-
With FQ_CoDel can I assume you are applying it outbound on WAN?
More likely to have issues doing that but others are seeing this on more regular Limiters/rules.
Kind of odd to see the traffic in the scheduler and not the limiter there....
Maybe because you're using child queues.
-
Hummm.
I've stumbled also on a limiter issue since 2.6.0.
Upgraded pfSense @home - using a Hyper-X, using a VM, so my interfaces are called 'hn0' and 'hn1'. It was a "Let's watch some Netflix show while doing this" user experience. It was less intrusive as an iPhone upgrade
I've been using using the "anti bloat limiters" from here : Playing with fq_codel in 2.4 (probably the biggest thread on this forum).
Jimp showed me recently that there is a dedicated pfSense Documentation on this subject now : Configuring CoDel Limiters for Bufferbloat.
On my @work pfSense, using a Dell 'something' I7 core with a quad Intel NIC (em0-em3), as soon as I create the floating firewall rule, all hell breaks loose. Unbound looses upstream connection. Restarting it shows to it tries to connect to the main 13 root servers, but noting gets resolved any more.
Note that I'm using the IPv6 tunnel setup from he.net - so I have a WAN IPv4 interface.
and a "HENET" that is IPv6 only. Is that a multiple WAN setup? I had, before, doubled my Up and down limiters, one set (up and down) for IPv4 and one set (up and won) for IPv6. That worked fine. Bloat testers were happy. I was happy.As soon as I activate one IPv4 or two (IPv4 and IPv6) of the floating rules, see under Create Floating Rule my pfSense goes in a state that floats between on-line and off-line.
Before, there was a floating firewall rule for the up stream, and one for the down stream. The up stream floating rule had a gateway set.
Before, ECN want not checked, now it is.I've rebooted in "simple" mode (console option 4) : just one WAN one LAN, no packages, no config.xml import : all is ok. As soon as I add the limiters as per 'official' documentation, that one floating firewall rule : something goes wrong.
Note that a ping "8.8.8.8" still works. But local resolving, for example, is out of business.My limiters info is the same as what @blikie shows :
Limiters: 00001: 22.000 Mbit/s 0 ms burst 0 q131073 1000 sl. 0 flows (1 buckets) sched 65537 weight 0 lmax 0 pri 0 droptail sched 65537 type FIFO flags 0x0 0 buckets 0 active 00002: 2.000 Mbit/s 0 ms burst 0 q131074 1000 sl. 0 flows (1 buckets) sched 65538 weight 0 lmax 0 pri 0 droptail sched 65538 type FIFO flags 0x0 0 buckets 0 active ..... Schedulers: 00001: 22.000 Mbit/s 0 ms burst 0 q65537 50 sl. 0 flows (1 buckets) sched 1 weight 0 lmax 0 pri 0 droptail sched 1 type FQ_CODEL flags 0x0 0 buckets 0 active FQ_CODEL target 5ms interval 100ms quantum 1514 limit 10240 flows 1024 ECN Children flowsets: 1 00002: 2.000 Mbit/s 0 ms burst 0 q65538 50 sl. 0 flows (1 buckets) sched 2 weight 0 lmax 0 pri 0 droptail sched 2 type FQ_CODEL flags 0x0 0 buckets 0 active FQ_CODEL target 5ms interval 100ms quantum 1514 limit 10240 flows 1024 ECN Children flowsets: 2 ......
I used the proposed "1000" bucket (slots) size, not "50".
So, what's up :
I can't read simple tutos any more ?
I need glasses ?
Double WAN issue ? ( I'll try tomorrow without any henet GIF IPv6 tunnel pollution ).
Or worse : the issue is as big as a house, so I can't see it ?And then this : on a VM with emulated, over complex virtual NIC 'hn' interfaces, it works.
Bare bone : it's a no go.Is this related ? :
@home this option is set, as I'm using hn interfaces.
Not at the work pfSense.I add more info when I find it.
-
@stephenw10 the same config has been working flawless since i started using pfsense2.4.5 nothing changed. Only when u run version 2.6, it breaks the internet access. It seems to be generating unknown packets in filter logs no.10 console.