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.

Connect to the console. Use option 11 - Restart webConfigurator and/or option 16 - Restart PHP-FPM Then hopefully you can reach the webGUI and look in the system log and maybe see what happened. If you have enabled SSH then you can SSH to the LAN IP and login from there also to get a "console" menu.

Yeah, I tried ee as well, similar results to VI. I figured that could do damage using a blind find/replace but I just wanted to actually boot into the system to do a factory reset. I didn't want to have to take apart the box to flash the SD card again. The script no matter what, wouldn't let me get through. I even tried using the "auto" method and it was using the same interface names I was typing with the same results.

I had a similar issue with FreePBX using the OSS End Point Device Manager. The above HTTP option worked OK with my newer Cisco VOIP phones but didn't work with some older Linksys VOIP phones. I had to revert the FreePBX back to TFTP provisioning and change the pfsense DHCP option 66 to: Number - 66 Type - Text Value - ipaddress or dnsname

Whilst a real switch will provide more bandwidth etc you can just bridge the ports to use a single subnet. Have a look here for an idea what to do: https://forum.pfsense.org/index.php?topic=48947.msg269592#msg269592 Steve

BUMP I know this is a boring as hell query but the good karma would surely be worth it, I'm dying here…  Thanks

@doktornotor: 48:F8:B3 Cisco-Linksys, LLC - what's that? That is a hidden DHCP server is what that is! Strange that it worked with the Tomato but not pfsense. That part really though me for a loop! I would have be my life that I check all the switches for such before I started. Guess I missed one. I really appreciate you guys walking me though this. Could I send ether/both of you a case of beer?

Can you describe exactly how it doesn't work?  You haven't given enough information to have a clue at all.  Are you testing from pfsense or from a LAN client?  If LAN client, are they static or DHCP?