@chrcoluk I did try that. Nothing, unfortunately, another ticket that I didn't was a restart to factory defaults.

@nbctcp said in SSH admin password should be the same as web admin right?: Could pfsense using port knocking like linux did? I mean telnet other port 3x then it will open port 22 Way back - like last century, I used such a method to gain access to private resources, while published on public networks. It worked well. These days we have (Open)VPN ;)

Hi @ACNiC - I've got a similar setup as yours with Pi-hole as the first DNS server and pfSense upstream. Avahi works just fine and I've never had any trouble with mDNS even with the IoT devices (such as Google Chromecasts, etc.) located on a different network segment than other devices. Couple questions: What exactly do you mean by "casting is not working"? Is is that you can't see / connect to e.g. Chromecasts from a device in a different network segment? Are your firewall rules setup properly to allow the necessary traffic to flow between device and IoT network so that casting can work? What options do you have checked under "Advanced DNS Settings" in Pi-hole? Hope this helps.

@serbus what command in php shell to reboot webconfigurator because I don't want to reboot system After testing various methods. Only viconfig and php shell work perfectly GOAL: Change Web GUI from http to https OPTION1 open http://ipaddress go to System/Advanced/Admin Access STATUS OK OPTION2 open gui console 8) Shell viconfig change webgui part from http to https /etc/rc.restart_webgui STATUS OK OPTION3 open gui console 12) PHP shell + pfSense tools parse_config(true); $config['system']['webgui']['protocol'] = "https"; write_config(); exec exit open gui console 11) Restart webConfigurator STATUS OK GOAL: Change Web GUI from https to http OPTION1 open http://ipaddress go to System/Advanced/Admin Access go to gui console 11) Restart webConfigurator STATUS GUI appeared, type username/password but can't login Shell shown "php-fpm[341]: /index.php: Successful login for user 'admin' from: 10.0.1.1" OPTION2 open gui console 8) Shell viconfig change webgui part from https to http /etc/rc.restart_webgui STATUS OK OPTION3 open gui console 12) PHP shell + pfSense tools parse_config(true); $config['system']['webgui']['protocol'] = "http"; write_config(); exec exit open gui console 11) Restart webConfigurator STATUS OK

Yes I would just move the required elements to the new install and you still wouldn't have to change the clients. But, yes, you could just forward traffic through the new unit to the old device as a VPN server. It's very easy to end up with an asymmetric route if you do that though. Steve

Doing fsck -y 4 times found more errors each time and after that, it all started up!! Thanks!

Update. I have swapped out the cable modem and this has solved my issue. Old modem was an Arris TG1682G. Upthread I said technicolor, I was wrong. New one is an Arris SB6190. I don't know if it was swapping the hardware or if the provisioning at comcast reset something, but it has been working for the last hour.

We are using Google's DNS servers, nslookups don't fail.

This happens with any web browser, too. Non-https web browsing works mostly fine when switched over to that mode but the status "up/no carrier" images on the Interfaces widget, the Traffic Graphs, the circle refresh symbol, etc. do not load immediately or correctly.

The system in production I've seen this first is SG-5100 with WAN igb0 and WAN2 ix1. My lab testing is VMware. -Rico

Hello, what problem is this? Crash report begins. Anonymous machine information: amd64 11.2-RELEASE-p10 FreeBSD 11.2-RELEASE-p10 #9 4a2bfdce133(RELENG_2_4_4): Wed May 15 18:54:42 EDT 2019 root@buildbot1-nyi.netgate.com:/build/ce-crossbuild-244/obj/amd64/ZfGpH5cd/build/ce-crossbuild-244/pfSense/tmp/FreeBSD-src/sys/pfSense Crash report details: No PHP errors found. Filename: /var/crash/info.0 Dump header from device: /dev/label/swap0 Architecture: amd64 Architecture Version: 1 Dump Length: 71680 Blocksize: 512 Dumptime: Thu Aug 20 22:23:13 2020 Hostname: Pfsense5.mtz.jovenclub.cu Magic: FreeBSD Text Dump Version String: FreeBSD 11.2-RELEASE-p10 #9 4a2bfdce133(RELENG_2_4_4): Wed May 15 18:54:42 EDT 2019 root@buildbot1-nyi.netgate.com:/build/ce-crossbuild-244/obj/amd64/ZfGpH5cd/build/ce-crossbuild-244/pfS Panic String: Dump Parity: 692791847 Bounds: 0 Dump Status: good Filename: /var/crash/textdump.tar.0 ddb.txt?????????????????????????????????????????????????????????????????????????????????????????????0600????0???????0???????140000??????13717630021? 7072? ?????????????????????????????????????????????????????????????????????????????????????????????????????ustar???root????????????????????????????wheel??????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????db:0:kdb.enter.default> run lockinfo db:1:lockinfo> show locks No such command; use "help" to list available commands db:1:lockinfo> show alllocks No such command; use "help" to list available commands db:1:lockinfo> show lockedvnods Locked vnodes db:0:kdb.enter.default> show pcpu cpuid = 0 dynamic pcpu = 0x898380 curthread = 0xfffff8000481d000: pid 12 "irq21: fxp0" curpcb = 0xfffffe004d975cc0 fpcurthread = none idlethread = 0xfffff800042e7000: tid 100003 "idle: cpu0" curpmap = 0xffffffff82b85998 tssp = 0xffffffff82bb6810 commontssp = 0xffffffff82bb6810 rsp0 = 0xfffffe004d975cc0 gs32p = 0xffffffff82bbd068 ldt = 0xffffffff82bbd0a8 tss = 0xffffffff82bbd098 db:0:kdb.enter.default> bt Tracing pid 12 tid 100066 td 0xfffff8000481d000 __mtx_lock_sleep() at __mtx_lock_sleep+0xcd/frame 0xfffffe004d975620 syncache_lookup() at syncache_lookup+0xc9/frame 0xfffffe004d975650 syncache_add() at syncache_add+0x16e/frame 0xfffffe004d9757a0 tcp_input() at tcp_input+0x1410/frame 0xfffffe004d9758e0 ip_input() at ip_input+0x139/frame 0xfffffe004d975940 netisr_dispatch_src() at netisr_dispatch_src+0xa8/frame 0xfffffe004d975990 ether_demux() at ether_demux+0x173/frame 0xfffffe004d9759c0 ether_nh_input() at ether_nh_input+0x32b/frame 0xfffffe004d975a20 netisr_dispatch_src() at netisr_dispatch_src+0xa8/frame 0xfffffe004d975a70 ether_input() at ether_input+0x26/frame 0xfffffe004d975a90 if_input() at if_input+0xa/frame 0xfffffe004d975aa0 fxp_intr() at fxp_intr+0x411/frame 0xfffffe004d975b20 intr_event_execute_handlers() at intr_event_execute_handlers+0xe9/frame 0xfffffe004d975b60 ithread_loop() at ithread_loop+0xe7/frame 0xfffffe004d975bb0 fork_exit() at fork_exit+0x83/frame 0xfffffe004d975bf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe004d975bf0 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- db:0:kdb.enter.default> ps

That thread hit the nail right on the head as far as I can tell! Awesome! I knew I wasn't searching the right terms, but I couldn't figure out what to use. Thanks for the help!

@chrcoluk I've decided in that way. ZFS with 2 SSD in mirror, and RAM disk. Hope it will run ok.

I can still think of no good reason to have to do that. To me that's a sign something in your config is broken. Are those three gateways in the same subnet on WAN? Which of them is actually defined on the WAN interface? What do you have set as the default IPv4 gateway in the GUI? You are setting the WAN IP address at boot every time. What IP does igb0 have if you do not run those commands? The only reason I can think of the interface would come up without an IP is if it conflicted with another interface somehow. Steve

@Gertjan Thanks for the great info. None of the statuses have reported incorrectly today so all good there. I'll check the sockets if/when it happens again. Only issue I'm seeing in the logs is, "WARNING: 'ifconfig' is present in local config but missing in remote config, local='ifconfig 10.255.27.9 10.255.27.10'" same as this old post https://forum.netgate.com/topic/31751/openvpn-ifconfig-warning ...and I've reached the same conclusons as the OP in that - in that I believe my configuration is correct and there's no config actually to correct in the web GUI. Doesn't seem related but just thought I'd mention it.

@Raffi_ said in Enable DNS over TLS via DHCP: Good point, yea could be more difficult to figure out what's going on with DNS The point is, don't release the 53 port out of the inner world...

Replying to own post to say that this problem is fixed - solution had nothing to do with pfSense.

Note : even excellent hardware can die on you.