@steveits And.... SOLVED it. Without the GUI, it's almost impossible to see real issues. WITH the GUI, the problem quickly became visible: Long ago, I created a final FW Rule on WAN allowing me to control logging of dropped packets. New Port Forward configs create FW pass rules on WAN... and places them at the end. Which means the above block rule means none of the port forward pass rules do anything ;) Disabled my block, and all is well!

@jkalber You're welcome. Just help someone else someday. :)

@mcury said in Site is on Squid proxy server Whitelist, but it is blocked: Allowed SSL ports, in squid configuration, does it include port 444? I did what you told me and it worked. I added the tip in the following fields: ACL SafePorts; ACL SSLPorts Thanks

You can just port forward the public IP to it for the required VPN ports. Or use 1:1 NAT for all ports. You could easily end up with some asymmetric routing though if the Firebox doesn't handle it correctly. Do you actually need a /16 on that LAN interface? Do you actually need those LAN side gateways defined in pfSense? They would only be required so that pfSense can access 192.168.0.0/24 for example. Steve

'Auto' allows the system to choose the default gateway based on what is up and in list order. If the DHCP WAN goes down and you have another gateway defined it will select that and, importantly, will not go back when the WAN comes back up. If you have internal gateways configured you should set the default to a specific gateway or group. Steve

If it doesn't show in the process list it's probably something in kernel like a driver. Are all the affected systems running on the same hardware? Steve

@johnpoz The isolation works as expected. When logged in to regular or Guest SSIDs I cannot ping or discover devices on the other network. That thread you referenced is a couple of years old. Apparently I bought my ORBI and satellites (last year) after the isolation issue was resolved or it was resolved in an update prior to my using the Guest SSID. And thanks for your answer to my previous question about using a separate NIC interface for WiFi on pfSense. Doing so I’ll be able to ensure control and isolation for my IoT devices and leave my Guest SSID just for….. guests.

Thanks Steve, I'll do some more tests. I understand now I don't need DHCP but using it ensures portable clients will get the PfSense DNS resolver and not their default network settings. When they get on another network they will get their IP address and DNS as normal. I think this has been my problem - Knowing when DNS lookup is coming from PFsense or from the VPN private DNS servers direct. My Windows setup is using my preset fixed IPs and specified DNS servers which are Google or the ISP. Big mistake! I hadn't thought about DHCP with static lease mappings but I'll research. I don't know if that will allocate the IP address I want unless PfSense can use client MAC addresses. When I do a DNS leak test, all my external IPs show as the VPN provider along with their DNS addresses looking similar to their IP address. I don't see Google! Without using the wrong network speak I'll explain what I and many others may want to achieve: Small home networks using standard ISP supplied routers can be compromised by the addon 'Smart' clients that people are now just plugging in without considering DMZs or sub nets. Some U.K TV streaming (BBC & Netflix) and bank sites look for the public IP address and geolocation to allow access to their services. VPN providers using shared and rotated IP addresses are often blocked. In a family home network the ability to block websites or non-approved connected clients is important. My pfsense setup at the moment is: Local Lan for PCs using fixed IP addresses. A small block of IP addresses is assigned to 2 firewall Aliases - 'Pass to VPN' or 'Bypass VPN' to WAN public IP. A DMZ interface with an IP address range for Smart TV, Media box and internet connected hard disc recorder. The DMZ accesses my Public IP. Any packets to or from the LAN are blocked. I regard the DMZ as low security. A wifi interface connected to the LAN on a fixed IP using VPN. This works for routing, blocking and allowing traffic, but I can't achieve DNS filtering. If I use DHCP fixed static mapping wouldn't there be uncertainty that another client could get the wrong IP? I may be dumb but it seemed to me that unless Pfsense could get a client MAC address it can't reliably use the rules set for it? I think that's why I concluded each client would need a fixed IP address and the pfsense DNS server address. On a small home network that's easy to configure for each client unless a wired laptop on a fixed IP moves elsewhere and won't connect wired to a DHCP router. WiFi connections aren't a problem because each connection on Windows defaults to DHCP. I'd like to use DHCP on PfSense, but I can't yet see how I can achieve selective routing?

@stephenw10 Thanks for the link. Yeah, but i think there may be a DNS problem, since nothing showed for over 2 hours after boot. Will pursue.

@ddave This is the post you want from BennTech. And yes, it does work. https://forum.netgate.com/topic/16217/howto-ping-hosts-and-reset-reboot-on-failure

@stephenw10 I did some reading on floating rules, I wasn't aware of that feature. That's great, thank you very much!

Alright I am back online after the help from Netgate support (huge freaking kudos to Alexey Prokofiev). He was able to edit my config from the SG-1000 I had and made it work for the SG-3100. Thanks again for everyone's help and recommendations. Office is back online!

@stephenw10 said in PfSense changes subnet in the nat rules!!: Either way it's fixed in 21.09 so... Which should be released any day ;) Since only a couple of days left in September (Month 9) hehehe..

That is not preventing DHCP. Link-local IPs are only assigned after DHCP has failed. They are non-routable and should be blocked. Steve

@h0110 said in BT FTTP & PFSense: Based on the the advice above from the other two members sendto error 65 has now disappeared, along with the 172.16.12.222 gateway IP. You are only not seeing that because you disabled gateway monitoring. I would suggest leaving that enabled and just disable the monitoring action so you are still logging the gateway response. You might also set the monitoring IP to something else since BTs gateways do not have to respond to ping at all. 8.8.8.8 is commonly used. If it won't respond to ctl+t at the console that is a hard lockup. I would be looking at a hardware issue at that point. Your setup is not unusual. Steve

@marco42 said in DNS Resolver stops working after pppoe_restart_pppoe0: I just checked the restart frequency and got this result: Keep in mind that these log files could have been rotated, which means older records have been purged. In that case, you'll find less results. Always have a look at the file, as log files are there to be looked at. Mine was rotated last month, on august 13 : Aug 13 14:36:00 pfsense newsyslog[90565]: logfile turned over due to size>1024K <31>1 2021-08-13T14:36:03.090423+02:00 pfsense.athome.tld unbound 799 - - [799:0] debug: validator[module 1] operate: extstate:module_state_ini> < ........ <30>1 2021-09-28T02:35:18.370449+02:00 pfsense.athome.tld unbound 45024 - - [45024:0] info: generate keytag query _ta-4f66. NULL IN

@ninthwave said in pfSense cannot get WAN IP after reboot: @gertjan Thanks. I know how to use pastebin. My problem is I cant download the log with WinSCP. [image: 1632768832529-5b83df89-0dcb-4369-877d-f9a37f3c6195-image.png] Can you guys starts another new thread? This is a year old already.

@johnpoz No doubt. I did at one point simply because I was lazy and didn't trust comcast to do the right thing if I swapped out a wrt54g. In my case, it actually saved me because my sg2440 fell victim to the red led of death, so moved one cable, rebooted wifes stuff and minimal downtime. (that sg2440 was fixed under RMA and has been working fine, but I've got a 5100 on order just in case). I always liked seeing the rules as applied (pf user before pfSense), that command helps me figure out exactly what is going on, you can mentally walk a packet flow.