I don't really have an environment to test that. But the static IP machines are not going to be getting any settings from a DHCP server. Normally the DHCP server would send them some default domain information that lets them learn a domain to use. So you probably need to either: a) Explicitly set the domain somewhere in the static clients or b) Set up some static mapping in the DHCP server so that those clients can use DHCP, and will thus get the domain name along with their static-mapped IP. Or I don't really understand the whole combination of systems/settings and someone else will have a good idea :)

I block the youtube with blacklist youtube.com and googlevideo.com.

$5/mo is pretty cheap for a static IPv4 address.  I'm being charged $20/mo for that with Verizon FIOS (who doesn't yet do IPv6).

Or consider installing "monit" on the pfSense box as a minimal tool.  You'll have to do it from command line.  I prefer Monit for small independent boxes, much easier to setup then Nagios/Zabbix/Icinga.

I used the OpenVPN client on my Android phone to troubleshoot my own OpenVPN setup. #1 Disable WiFi on the phone #2 Fire up OpenVPN client and connect to my VPN #3 Do testing on the phone That was enough for me to figure out whether OpenVPN was configured properly on pfSense. (I'll have to try the Android phone as a WiFi hotspot idea as well.)

Yes, it seems to be the modem - what a piece of shit! The MAC address is key… if I hadn't had a 'virgin' Alix box, I don't think I would have ever got this working. I've replicated its MAC to both fw1 and fw2, and they now both work fine; they can reach the 'update' site. The perverse behavior of this modem would seem to completely rule out using the failover feature - if it was ever possible on a bridged modem. I've still got one question: Is there any historical data on the pfsense box that the cable modem could access during DHCP? I ask because when fw1 (and subsequently fw2) was connected to the bridged cable modem, I observed that pfsense reported a gateway address that it used when it was connected to another gateway device (the router for the fixed-IP service). I totally don't understand how pfsense could report such nonsense.

Watch, Charon isn't flagging memory pages to not be paged out then the kernel attempts to access said memory locations.

@phil.davis: Should I just replace that file with what you have there? or Should I upgrade to pfSense 2.2.3 after the backup config? Will upgrading to 2.2.3 give me clean copies of all the code? Yes, you could paste in the proper code from https://raw.githubusercontent.com/pfsense/pfsense/RELENG_2_2/usr/local/www/diag_logs_resolver.php and fix this file. That would fix the current problem you see. But if you do not know how the wrong code got there in the first place then who knows what other code or files are also not right. Upgrading to pfSense 2.2.3 will give you clean copies of the code. Maybe fix up the code in diag_logs_resolver.php for now, then upgrade to 2.2.3 in a couple of days (doing a full backup along the way…) You could also backup the config, reinstall 2.2.2, reload the config, let all the packages reinstall. That will bring you back to known good 2.2.2 Just paste your code. It fixed that problem, big thanks to you. I will wait for couple days before upgrade to 2.2.3. Thanks again.  ;D

Thank you for the reply, but the extra services from Watchguard are not needed. The Watchguard OS with the basic services included, are just fine. Greetz DeLorean

Press enter and you should get the menu. In the menu you could choose 'Halt System'. Otherwise reboot if possible and look at the terminal window while booting. APU startup is 115200. If you upgraded hardware and used an old config it's possible you should choose 9600 to see pfSense booting. [image: terminal.jpg] [image: terminal.jpg_thumb]

You can customize the unifi portal to your hearts content so putting a link to a CA cert should not be a problem.  Or just using a trusted signed cert should remove that problem all together. You are correct mdns can be a pita, think the ttl is 1, etc.  I solved it even easier way by just putting my printer on the wlan segment ;)  Before that I had done it with cups, where my cups server just had an interface in the wlan segment as well.  Then I didn't have to worry about running cups.

@stephenw10: Hmm, you're seeing the traffic blocked in the firewall log? I assume you have rules on LAN to allow it? If you can't ping from diagnostics then there's no chance of accessing anything from LAN. Check the ppp log. Steve Here is my ppp log. Jun 25 21:32:25 ppp: [wan] IPV6CP: Open event Jun 25 21:32:25 ppp: [wan] IPV6CP: state change Initial –> Starting Jun 25 21:32:25 ppp: [wan] IPV6CP: LayerStart Jun 25 21:32:25 ppp: [wan] IPCP: Up event Jun 25 21:32:25 ppp: [wan] IPCP: state change Starting –> Req-Sent Jun 25 21:32:25 ppp: [wan] IPCP: SendConfigReq #1 Jun 25 21:32:25 ppp: [wan] IPADDR 0.0.0.0 Jun 25 21:32:25 ppp: [wan] COMPPROTO VJCOMP, 16 comp. channels, no comp-cid Jun 25 21:32:25 ppp: [wan] PRIDNS 0.0.0.0 Jun 25 21:32:25 ppp: [wan] SECDNS 0.0.0.0 Jun 25 21:32:25 ppp: [wan] IPV6CP: Up event Jun 25 21:32:25 ppp: [wan] IPV6CP: state change Starting –> Req-Sent Jun 25 21:32:25 ppp: [wan] IPV6CP: SendConfigReq #1 Jun 25 21:32:25 ppp: [wan] IPCP: rec'd Configure Request #1 (Req-Sent) Jun 25 21:32:25 ppp: [wan] IPADDR 150.101.199.219 Jun 25 21:32:25 ppp: [wan] 150.101.199.219 is OK Jun 25 21:32:25 ppp: [wan] IPCP: SendConfigAck #1 Jun 25 21:32:25 ppp: [wan] IPADDR 150.101.199.219 Jun 25 21:32:25 ppp: [wan] IPCP: state change Req-Sent –> Ack-Sent Jun 25 21:32:25 ppp: [wan] IPCP: rec'd Configure Reject #1 (Ack-Sent) Jun 25 21:32:25 ppp: [wan] COMPPROTO VJCOMP, 16 comp. channels, no comp-cid Jun 25 21:32:25 ppp: [wan] IPCP: SendConfigReq #2 Jun 25 21:32:25 ppp: [wan] IPADDR 0.0.0.0 Jun 25 21:32:25 ppp: [wan] PRIDNS 0.0.0.0 Jun 25 21:32:25 ppp: [wan] SECDNS 0.0.0.0 Jun 25 21:32:25 ppp: [wan] IPV6CP: rec'd Configure Request #1 (Req-Sent) Jun 25 21:32:25 ppp: [wan] IPV6CP: SendConfigAck #1 Jun 25 21:32:25 ppp: [wan] IPV6CP: state change Req-Sent –> Ack-Sent Jun 25 21:32:25 ppp: [wan] IPV6CP: rec'd Configure Ack #1 (Ack-Sent) Jun 25 21:32:25 ppp: [wan] IPV6CP: state change Ack-Sent –> Opened Jun 25 21:32:25 ppp: [wan] IPV6CP: LayerUp Jun 25 21:32:25 ppp: [wan] 98dc:de48:e85a:af62 -> 0224:14ff:fe9a:b910 Jun 25 21:32:26 ppp: [wan] IFACE: Up event Jun 25 21:32:26 ppp: [wan] IFACE: Rename interface ng0 to pppoe0 Jun 25 21:32:26 ppp: [wan] IPCP: rec'd Configure Nak #2 (Ack-Sent) Jun 25 21:32:26 ppp: [wan] IPADDR 121.44.201.118 Jun 25 21:32:26 ppp: [wan] 121.44.201.118 is OK Jun 25 21:32:26 ppp: [wan] PRIDNS 192.231.203.132 Jun 25 21:32:26 ppp: [wan] SECDNS 192.231.203.3 Jun 25 21:32:26 ppp: [wan] IPCP: SendConfigReq #3 Jun 25 21:32:26 ppp: [wan] IPADDR 121.44.201.118 Jun 25 21:32:26 ppp: [wan] PRIDNS 192.231.203.132 Jun 25 21:32:26 ppp: [wan] SECDNS 192.231.203.3 Jun 25 21:32:26 ppp: [wan] IPCP: rec'd Configure Ack #3 (Ack-Sent) Jun 25 21:32:26 ppp: [wan] IPADDR 121.44.201.118 Jun 25 21:32:26 ppp: [wan] PRIDNS 192.231.203.132 Jun 25 21:32:26 ppp: [wan] SECDNS 192.231.203.3 Jun 25 21:32:26 ppp: [wan] IPCP: state change Ack-Sent –> Opened Jun 25 21:32:26 ppp: [wan] IPCP: LayerUp Jun 25 21:32:26 ppp: [wan] 121.44.201.118 -> 150.101.199.219

Your ISP shouldn't let you get there. It's certainly a bit odd, but I doubt it's anything to be concerned with. It looks like a reply from a HTTPS server to a connection you initiated, but somehow the reply got sourced from a private IP, and made it across the Internet back to you. If we were in an ideal world that shouldn't be possible, but a lot of ISPs don't filter that traffic ingress (or egress at times). What likely happened is you connected to some HTTPS site whose network was broken in such a way that some server routed replies back without NAT happening to translate it back to the public IP you actually connected to in the first place. If it continues, it's worth investigating what's happening. If not, don't worry about it.

dude even if it was ask 1st, then ask 2nd – when 1st answers back with NX.. its not going to go ask the second one.  Even if it did, it would be a horrific setup for efficiency..  Where does it resolve public stuff?  So you have how many dns servers listed.. And you want it to go down the line asking every single 1 every time something needs to be resolved? Its a not a big problem at all, you just need to understand how dns works and the products your using feature set to correctly set it up. Trying to use 4 different dns servers that don't exchange information for same domain is not going to be a good setup. You could use subdomains like site1.yourdomain.tld, site2.yourdomain.tld, etc.. Then when client in site1 asks for host.site2.yourdomain.tld there could be an over ride in pfsense site 1 dns forwarder to point to site2 pfsense to resolve it.