Upgrade 2.5.2 to 2.6.0, upgrade success, Limiters not passing
-
I don't think it is that but you can easily test that theory by switching to DNSMasq.
-
@thiasaef said in upgrade 2.5.2 to 2.6.0, upgrade success, no internet conection:
I bet my ass that the issue is related to the DNS Resolver being fucked up once again.
i use DNS Forwarder so i cant blame DNS Resolver since i get the same problem.
-
@stephenw10 I would probably do that for testing purposes, if I still had 2.6 installed.
The only thing I can tell you is that it repeatedly stopped working on some LAN networks while still working on others, and I could always fix the problem by restarting DNS Resolver once or twice and doing nothing else. After a day of problems, with no solution in sight, I had no choice but to downgrade.
-
@stephenw10 Yes, with separated rules , traffic stopped to be working on rule where was limiter. I also find another issues, so I switched to second device for now as there was lot of issues :-/
-
Ok, it looks like you had/have a captive portal active there which I think it probably the source if the issues you are seeing.
In fact in fact I think a lot of the issues that look like Limiters may be and that's why replicating it has proved difficult.
Anyone here seeing connectivity issues on interfaces with Limiters without Captive Portal running?
Steve
-
@stephenw10 I should have tested turning off captive portal first before downgrading. captive portal might be the culprit here.
-
@aju_flex Same thing on me too. I have 8 VLANs, and after upgrading to 2.6.0 limiters started to block internet. As soon take off limiters on IN/OUT pipeline it is working fine. It is annoying bug, downgrading to 2.5.2.
-
Hi
I have no captive portal on this interface, not using dns forwarder or resolver.
Clients get OpenDNS server from dhcp server config.If I enable limitiers on the second rule, I cannot access http://1.1.1.1 from a browser.
-
@tohil said in upgrade 2.5.2 to 2.6.0, upgrade success, no internet conection:
If I enable limitiers on the second rule, I cannot access http://1.1.1.1 from a browser.
Small, not related detail :
Even when I'm not using pfSense, http://1.1.1.1 doesn't producing anything.
1.1.1.1 is a DNS resolver, listing over port 53 UDP and TCP. Why do you think it listening on port 80 TCP ? -
i mean https 443. check https://1.1.1.1/
-
I don't know if my problem is related to this post .. I have more than 20 PfSense installed, in general the upgrade from release 2.5.2 to 2.6.0 went well, but, on two firewalls that use limiters, updated yesterday , it happened that the natted ports (tcp and udp) were no longer reachable (regulated by the limiters), a downgrade to the 2.5.2 release completely solved the problem.
-
@luca-de-andreis
inbound NAT? Destination NAT?maybe source NAT is the issue with internet access for the other issues here....
-
@tohil
Dnat, from wan to internal segment.
I use limiters massively and the nat traslation doesn"t work (tested on 2 different firewall).
Rollback on 2.5.2 and the same setup works perfectly. -
@luca-de-andreis said in upgrade 2.5.2 to 2.6.0, upgrade success, no internet conection:
the nat traslation doesn"t work
Are you seeing traffic simply not being NAT'd? So no states with NAT opened? Traffic just blocked hitting the WAN with the external address still?
Steve
-
Hi Steeve
Unfortunately the firewalls in question are in full production (we would like to migrate them all to the plus version with advanced support soon). One was updated yesterday morning (2.5.2 -> 2.6.0) the other, yesterday evening (same version change). And everything worked fine for a few hours. Only today we realized that the firewalls were active, but no UDP or TCP port in dnat (from WAN to several internal segments) did not work, we did not investigate the matter, but as quickly as possible we did a version rollback ( all firewalls are in QEMU-KVM and it is our habit to run the snapshots of the VMs for several days post upgrade). So we do not know in detail the cause of the problem, we only have some indications: use of limiters, correct operation in the first hours of operation, if the firewall is restarted the nat (with limiters) returns to work. Rollback to version 2.5.2 and everything is back to working perfectly.
Thanks
Luca -
@thiasaef said in upgrade 2.5.2 to 2.6.0, upgrade success, no internet conection:
I bet my ass that the issue is related to the DNS Resolver being fucked up once again.
I stand corrected, I have the exact same issue in 2.5.2, sorry!
By the way: When I set the DNS server via DHCP to something other than the firewall itself, it works fine on all LAN interfaces.
-
@thiasaef said in upgrade 2.5.2 to 2.6.0, upgrade success, no internet conection:
I stand corrected, I have the exact same issue in 2.5.2, sorry!
Which does not make it any better to be honest. How is it possible that a major issue like this that is known for at least 2 months, makes it into a release like 2.6.0?
-
This thread is getting very confusing, there's at least three different issues being discussed.
It's mostly about Limiters not passing traffic though so let's keep it for that. Please open a new thread for Unbound problems.Steve
-
Hello,
Looks like I am late to the party, but we are also experiencing this issue with our limiters since the upgrade to 2.6.0. I have 2 different limiters configured on 2 different inside interfaces. No NAT in use on either interface. Each interface has a subnet of public routable IPs. The limiters were configured to rate limit specific host IPs within each subnet and worked as expected under 2.5.2. Now they block traffic. Can not even ping from the limited host to the interface IP. Removing the limiter from the In/Out Pipes immediately restores full connectivity.
I have watched the Limiter Info output and it appears to be hard limiting to 50 packets and then dropping everything after that point if I am reading this correctly? Every time I re-add the limiter I can ping until this number hits 50 and then everything stops.
00008: 27.000 Mbit/s 0 ms burst 0
q131080 50 sl. 0 flows (1 buckets) sched 65544 weight 0 lmax 0 pri 0 droptail
sched 65544 type FIFO flags 0x1 256 buckets 1 active
mask: 0x00 0xfffffff8/0x0000 -> 0x00000000/0x0000
BKT Prot Source IP/port_ Dest. IP/port Tot_pkt/bytes Pkt/Byte Drp
168 ip 66.###.###.40/0 0.0.0.0/0 4975779 1355919070 50 10861 2291 -
Hmm, interesting. Seems likely that's because the queue length is 50 packets by default.
If you can try setting the queue length to something longer and see if that changed the number of passed packets.
To be clear you see replies to the first 50 pings?
Hard to see how it could be filling the queue but passing at the same time.Steve
