Upgrade 2.5.2 to 2.6.0, upgrade success, Limiters not passing
-
The same thing happened to me yesterday after upgrading to 2.6.0. I dont even have limiters set up. At first i thought it might be a realtek issue but i tried installing the drivers from here https://forum.netgate.com/topic/166746/realtek-re-kmod-missing-in-pfsense-2-6-repository and same thing happened still no internet. It might still be a realtek driver unless someone here with different NIC experiences the same problem. Check using Diag > Ping and the pfsense able to ping websites it just cant give internet to my network.
So i gave up for now and reverted back to 2.5.2
-
Most clients will attempt to send ntp traffic at least. You should see that in the states. It will probably try to use the interface IP directly though which may not hit the issue.
You can just try a udp traceroute.Steve
-
@stephenw10 no it seem, that it was working only because I have separated FW rules for ICMP and UDP. When I now make one rule for all and set here limiters, nothing was working.
One maybe strange think is, that I see in states traffic from devices that are few hours disconnected from network, this is ok? States arent reseting itself?
-
I bet my ass that the issue is related to the DNS Resolver being fucked up once again.
-
@georgecz58 said in upgrade 2.5.2 to 2.6.0, upgrade success, no internet conection:
When I now make one rule for all and set here limiters, nothing was working
There is two way traffic shown there but clients in the WIFI_231 subnet are unable to connect at all with that ruleset?
With the separate rules enabled do you see states/traffic shown for all three protocols?
Steve
-
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
