@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?

OK fine I'm sorry for pissing off anyone. I appreciate the efforts in trying to help. I am very happy to have everything working well again!

@-RYknow: Ohh… ok. Well then, what would the answer be to that question? Maybe I should clarify that my issue is while using a VPN. If I'm not using my VPN, everything works just fine. I don't know much about pfsense at all, but in my poking around I found there is quite a number of errors that appear squid related in the firewall section. Here are a few; Jun 22 20:00:03 php: rc.filter_configure_sync: There was an error while parsing the package filter rules for /usr/local/pkg/squid.inc. Jun 22 20:00:01 php: rc.filter_configure_sync: The command '/sbin/pfctl -nf /tmp/rules.test.packages' returned exit code '1', the output was '/tmp/rules.test.packages:21: syntax error' I'm completely clueless what this all means. I haven't changed anything with squid, nor updated anything? I'm running 2.2.2 on a netgate APU. Any help would be greatly appreciated. There's been a galore of issues with Squid* on 2.2.x; obviously when your firewall rules are broken by it, it's not a good thing. Look at the reported line and see what's there. Otherwise, there's a dedicated subforum for Squid and proxy junk in general.  :P

Ha!  ;D Somewhat off topic but amusing anyway.

Obvious question, but which NIC are you trying to access the box from? Unless you've made specific changes to the rules, by default you won't be able to access the management GUI from the WAN side, only the LAN.

If you want low-cost and reasonably power-efficient, consider a refurb SFF (small form factor) PC with a Core2Duo that is at least 2GHz.  I have a 3GHz (E8400) with SSD and a dual-port Intel NIC that only pulls 38W when idle and 50-65W under load.  It cost me $75-$85.  I spent more on the refurbed dual-port Intel low-profile NIC and the SSD. There are dozens/hundreds of reburbs out there with 90 day warranties from places like NewEgg. My estimate is that the C2D 3GHz would be able to handle about 1.2-1.5 Gbps of bidirectional traffic routing.  Maybe 1/2 to 1/3 of that if used with a lot of packages or VPNs.  Since I only have a 50/50 WAN and only need about 100Mbps between the various VLANs, it's enough for the moment.