@Gertjan @stephenw10 Thank you for the explanations. I will start a new thread.

(Hice un post pero lo elimine ya que han cambiado ciertos asuntos, este es un post actualizado) Hola, seré breve Tengo el router ISP que va conectado a un switch el cual se encarga de separar en vlans el router ISP del pfSense, ya que mi idea era separar la red ISP de la mia para montarme mi homelab, pero manteniendo la red ISP, o sea estoy en doble NAT Tengo suricata y pfBlockerNG, pero pfBlockerNG ahora no lo utilizo Deshabilité IPv6 por completo, en caso de que hubiera un conflicto, y después de hacerlo, comenzó a resolver consultas con DNS externo, pero daba "Respuesta no autoritativa" [image: 1756816982004-consulta-a-dns-externa.png] Si hago un nslookup normal a google.com (por ejemplo) utilizando una DNS externa como 8.8.8.8 reconoce la dirección pero el servidor no [image: 1756817020179-consulta.png] Y si hago un nslookup directo a pfSense con google.com, reconoce el servidor pero termina dando error [image: 1756817525833-consulta-directa-a-pfsense.png] Aquí están mis ajustes del unbound: [image: 1756817739983-captura-de-pantalla-2025-09-02-145314.png] [image: 1756817880184-captura-de-pantalla-2025-09-02-145329.png] No se que puede estar pasando Supongo yo que es por este problema por el que no cargan las páginas y demás aunque en el cliente luego me pone que hay acceso a internet Gracias de antemano

@hossazaw said in Installing Openvpn package: I found the url on gpt and also searched for the package in the website but with no luck pfSense has its own 'package servers url' build in. Like Windows : no need to specify where to look for updates, Windows knows how to call home. be ware : if if you found that url, you can't use it with a web browser. It's a package server, not a web server. @hossazaw said in Installing Openvpn package: Whenever I tried to install the package from Webgui, it says "Please wait while the update system initializes" and nothing happens. A possible reason : and by far the most obvious one : DNS is broken. The code (script) used to request the package list is somewhat resilient, and won't take no for an answer that quickly, and will stay in memory for some time, trying many times. It could be a non local temporary DNS issue after all. All this time, only one instance of this script is allowed, subsequent requests from your (GUI) side will get "Please wait while the update system initializes" as an answer. If DNS couldn't be used by the update script, because it (for pfSense itself) doesn't work, it can take quiet a while before it times out. Subsequent request will also fail. To see better what actually happens : Use the SSH or console access, option 8. Start by reading this one : Troubleshooting Upgrades.

@HidekiSenpai not sure why you think a query to quad9 would be authoritative.. quad9 is not the authoritative ns for google.com Your unbound setting there are resolver mode, for you to be able to resolve you would have to be able to talk to all the NS on port 53.. If your upstream is blocking this then yeah your going to have issues. What does dns lookup on the diagnostic menu dns lookup report? To test if you can resolve and to see where you might be having issues do a dig + trace on pfsense. [25.07.1-RELEASE][admin@sg4860.home.arpa]/root: dig google.com +trace ; <<>> DiG 9.20.6 <<>> google.com +trace ;; global options: +cmd . 84617 IN NS d.root-servers.net. . 84617 IN NS f.root-servers.net. . 84617 IN NS e.root-servers.net. . 84617 IN NS m.root-servers.net. . 84617 IN NS j.root-servers.net. . 84617 IN NS b.root-servers.net. . 84617 IN NS c.root-servers.net. . 84617 IN NS g.root-servers.net. . 84617 IN NS k.root-servers.net. . 84617 IN NS l.root-servers.net. . 84617 IN NS a.root-servers.net. . 84617 IN NS h.root-servers.net. . 84617 IN NS i.root-servers.net. . 84617 IN RRSIG NS 8 0 518400 20250915050000 20250902040000 46441 . r2EKEjvLOSDMWT4XAMJK+3McQntRgJ/wtG2WXCZ90DdKxUgNUCU1Q1R+ YDovtNQExt87dM1gu8S10al5FJPNkLM6pbQM010+1E2AnyCQyt4DQrJh JgMhwcYONIbT/gGrXfQS7sdN8B5g0ob2HcqXRxqMkDOldxdBCJy7B5ZM AufoQlrCrdazkGHVxC+vzsDIDVYnAFLlLkoHtcpbLmiK1w6MiVNfzfWt EC4v7Bibau5rMYzhYZ0EwGv4CCG6dn8HiGEg0rNBmMi7onXndKhq2S4H T9b1jkIj1qG1GfVOzVuqmzv7OWgW9+0jbqel3VR7AAfO9plH7JLeVNY1 EmTLTg== ;; Received 525 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms com. 172800 IN NS a.gtld-servers.net. com. 172800 IN NS b.gtld-servers.net. com. 172800 IN NS c.gtld-servers.net. com. 172800 IN NS d.gtld-servers.net. com. 172800 IN NS e.gtld-servers.net. com. 172800 IN NS f.gtld-servers.net. com. 172800 IN NS g.gtld-servers.net. com. 172800 IN NS h.gtld-servers.net. com. 172800 IN NS i.gtld-servers.net. com. 172800 IN NS j.gtld-servers.net. com. 172800 IN NS k.gtld-servers.net. com. 172800 IN NS l.gtld-servers.net. com. 172800 IN NS m.gtld-servers.net. com. 86400 IN DS 19718 13 2 8ACBB0CD28F41250A80A491389424D341522D946B0DA0C0291F2D3D7 71D7805A com. 86400 IN RRSIG DS 8 1 86400 20250915050000 20250902040000 46441 . PuEt7PPZTytXpON7kI4PR4ePmn1RbbZwWwksIwQqStFADSXkHLtaCWBk 6rjtDQogfGqqcRZnJzXTwq7FD+lsB//y3DBBkzBB+ag7XmldiFGtkV3Y 9ueUEL4ydZnyftPClzOtBYbtzMVA2oC6gfNbi7LyIFUUH8xc0IZUPJah 9IQF443ZocHNNl8jPpSilA7QVkSf6rKRH5CNUdTsJ6qhfXUEOWgNqIaV yLCrPzsnyl7+PoU1dBpPmsbUY0DUO2A0E5Zs5lBpcgjThoEK/SMokB1v Rb75/7Yvb+MGyDWmZVwd9uKdVadxzn6jdJgxgSM+SBuxaSpkWlnqhJnx fYnP/w== ;; Received 1170 bytes from 2001:503:c27::2:30#53(j.root-servers.net) in 9 ms google.com. 172800 IN NS ns2.google.com. google.com. 172800 IN NS ns1.google.com. google.com. 172800 IN NS ns3.google.com. google.com. 172800 IN NS ns4.google.com. CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 900 IN NSEC3 1 1 0 - CK0Q3UDG8CEKKAE7RUKPGCT1DVSSH8LL NS SOA RRSIG DNSKEY NSEC3PARAM CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 900 IN RRSIG NSEC3 13 2 900 20250908002603 20250831231603 20545 com. I5bq7mPPNzfXbaaD27hOUwaUOIQJi6EcJYwN+Ab4FiMqp5GgoHWsfgSm LHUn2Mg3jXAGfxykTCnJXfUQYtJ+oQ== S84BOR4DK28HNHPLC218O483VOOOD5D8.com. 900 IN NSEC3 1 1 0 - S84BR9CIB2A20L3ETR1M2415ENPP99L8 NS DS RRSIG S84BOR4DK28HNHPLC218O483VOOOD5D8.com. 900 IN RRSIG NSEC3 13 2 900 20250909012623 20250902001623 20545 com. 1Sn2h2Xvf9GUFWqqEDwCOD+aZFVhrEhV+87H/RxeCGuNoA42E7tz5Oq6 A7hnIkd0J8coWN0C9M9gQlJLjrrfvw== ;; Received 644 bytes from 192.26.92.30#53(c.gtld-servers.net) in 27 ms google.com. 300 IN A 172.217.2.46 ;; Received 55 bytes from 216.239.36.10#53(ns3.google.com) in 25 ms The dig + trace is exactly what the resolver would do - so seeing all the steps can show you were you might be failing in the process.

@rds25 said in Captive Portal: Restrict Ports for Allowed IP Address?: As far as I understand, IPs listed under "Allowed IP Addresses" completely bypass the rules defined in the "PORTAL" tab. That's what I initially also thought. This is the portal rule that blocks all portal-to-LAN IPv4 traffic : [image: 1756797401971-c9aa3733-1739-40f8-b7cf-757f4f3abb37-image.png] I connected my phone to the portal, it got 192.168.2.10, and then I started to send ICMP packets to 192.168.1.33. While doing so, I was packet capturing on my portal interface for ICMP traffic, send by 192.168.2.10, my phone. I saw the packets, ICMP requests, coming in - but no answers logged. At the same moment, I was : [25.07.1-RELEASE][root@pfSense.bhf.tld]/root: tail -f /var/log/filter.log and I saw : ... <134>1 2025-09-02T09:15:05.661320+02:00 pfSense.bhf.tld filterlog 75062 - - 164,,,1655045805,igc1,match,block,in,4,0x0,,64,271,0,none,1,icmp,84,192.168.2.10,192.168.1.33,request,63694,1564 <134>1 2025-09-02T09:15:06.661321+02:00 pfSense.bhf.tld filterlog 75062 - - 164,,,1655045805,igc1,match,block,in,4,0x0,,64,52479,0,none,1,icmp,84,192.168.2.10,192.168.1.33,request,63694,1664 <134>1 2025-09-02T09:15:07.661337+02:00 pfSense.bhf.tld filterlog 75062 - - 164,,,1655045805,igc1,match,block,in,4,0x0,,64,19671,0,none,1,icmp,84,192.168.2.10,192.168.1.33,request,63694,1764 <134>1 2025-09-02T09:15:08.661389+02:00 pfSense.bhf.tld filterlog 75062 - - 164,,,1655045805,igc1,match,block,in,4,0x0,,64,9817,0,none,1,icmp,84,192.168.2.10,192.168.1.33,request,63694,1864 <134>1 2025-09-02T09:15:09.661321+02:00 pfSense.bhf.tld filterlog 75062 - - 164,,,1655045805,igc1,match,block,in,4,0x0,,64,17809,0,none,1,icmp,84,192.168.2.10,192.168.1.33,request,63694,1964 <134>1 2025-09-02T09:15:10.661336+02:00 pfSense.bhf.tld filterlog 75062 - - 164,,,1655045805,igc1,match,block,in,4,0x0,,64,16478,0,none,1,icmp,84,192.168.2.10,192.168.1.33,request,63694,2064 <134>1 2025-09-02T09:15:11.661399+02:00 pfSense.bhf.tld filterlog 75062 - - 164,,,1655045805,igc1,match,block,in,4,0x0,,64,17854,0,none,1,icmp,84,192.168.2.10,192.168.1.33,request,63694,2164 <134>1 2025-09-02T09:15:12.661402+02:00 pfSense.bhf.tld filterlog 75062 - - 164,,,1655045805,igc1,match,block,in,4,0x0,,64,34051,0,none,1,icmp,84,192.168.2.10,192.168.1.33,request,63694,2264 ... which tells me that my firewall rule (shown above) was blocking my ICMP requests (to 1492.168.1.33). GUI equivalent : [image: 1756797907823-8d2a4a54-06d5-45d4-afb3-c5e359d61e79-image.png] The firewall log label is "LAN Block" so I knew which firewall rule was blocking, the one I showed above. This really makes me think that even when you Allow an IP address, the portal's GUI firewall rules still apply. As soon as I activated this first portal's firewall line : [image: 1756797755652-ed4331af-495b-42e3-ae7e-5464c718cba4-image.png] which allows ping packets from the portal interface to go to my LAN, 192.168.1.33, my NAS, ping packets came back / the NAS was replying.

Wa salam, I'm also new and I have a question but don't know from where I start do you have any experience?

Update from my side: issue hasn't appeared again since disabling ntopng, so seems that was the culprit (or one of them, anyway).

@jacksonp Well that’s unexpected also, haven’t had that sort of issue across our clients. I think the only reinstalls on 2100s were for the EFI issue.

@tman222 I've got T-Mobile Home Internet (THMI) set up as my backup to Starlink in a pfSense failover gateway group. It is kept alive by a ping to 8.8.8.8 and my gateway always has the ipv4 address of 192.168.12.1. The pfSense interface gets .12 address, right now, .12.145. For science, I turned on ipv6 dhcp to get the one and only ipv6 address from the TMHI gateway and it did get an ipv6 address it couldn't really do much with, kept alive by pinging the ipv6 of 8.8.8.8. Until it didn't work. One day the ipv6 address and interface was just dead and the ipv6 address wouldn't come back with some usual efforts. Since it was just an experiment, I shut the ipv6 off. Since TMHI won't give a prefix, it's really not much use that I can tell to have the router interface have an ipv6 address with nothing else downstream. So it just uses ipv4. Note, I have shut off all the wifi on the box and just use it through the ethernet port. I used a great IOS app called HINT Control to shut off the wifi on the TMHI gateway. I have my own wifi, so I don't need it polluting the em spectrum with more. Since we live in the sticks, both our Starlink and TMHI use CGNAT of a sort but I don't have any problems with double-NAT with either. It just works.

foranalyze2.anonymized.txt

@tman222 Yeah I don’t know that is possible. With IPv4 NAT the PCs have one IP. With IPv6 they’d need one from each interface. So maybe https://docs.netgate.com/pfsense/en/latest/network/ipv6/nat.html but then the device would need to not use it since it wouldn’t work normally. And generally it’s the preferred protocol.

@SteveITS said in Rules not blocking guest network from firewall or other VLANS: because something doesn’t match: source/interface, port, destination. Completely agree - but with the rule he is showing ipv4+6 any any to any firewall IP.. It would clearly match trying to open up the webgui of pfsense. But clearly it shows it has never triggered with that 0/0 - so 2 things that come to mind is there is a state currently open that is allowing the traffic even with the block rule added. Other is there is a floating rule that is triggered to allow it before that rule would get evaluated. edit: other thing would be he is not actually talking to pfsense via that specific interface, and the interface being used has different rules that allow the access. So would like to see floating tab rules, take a look in the state table. Like to see clients IP address.. With that rule in place a client on the guestlan subnet should not even be able to ping the pfsense guestlan IP 192.168.30.1 let a lone access the gui.

I cannot say more about questions Q1 and Q2. About Q3. I have a PPPoE line, 1Gbps/300Mbps, MTU is 1492. My line is fine also without limiters, I had a solid A for bufferbloat, RTT is 6ms (first hop) I tried limiters, using 1506 as quantum (1492 + 14 interface overhead), set limit at 7ms for download and 5ms for upload, bandwidth (950/285) I tested with thoese limiters, set the floating rules as per netgate instructions, and now I have a solid A+ on bufferbloat test, with average speeds of 930/280. I suggest to test against bufferbloat issues before using limiters, then repeat the test using limiters so you can see if they are working and improving latency management.

@stephenw10 Thank you for providing these commands, and confirmation more logging is coming as well. The ISP is still investigating, I did setup an auto recovery mechanism which involved rebooting pfSense after 3 failed responses from the gateway in a 3 minute period, but now with the down up commands this will be a quicker and cleaner process, and since cycling the ppp is far less of an interruption than rebooting, I can do it without waiting 3 minutes as well. https://forum.netgate.com/post/1223518

I think you may be over reacting to users questions. There are plenty of things pfSense could be better at! Most commonly when we see reports of some service that worked fine behind some other router but not pfSense it's either a NAT issue or some ALG/Proxy that was present on the other device but not in pfSense. Try setting a static source port. The difficulty here is that it doesn't fail immediately. It looks as though the ecobee server marks the IP address bad in some way after some time and presumably after some conection event that pfSense fails to pass. But we have yet to see exactly what that is which makes it difficult to diagnose.

Mmm, I've never seen that here either.

@kprovost you've been kind enough to review, test and merge the PR. Maybe you could help me do a similar kind of build as you did?