If there's no output at all on the serial port the hardware is dead. You should always see something from Coreboot even if there's no media present. The only possible exception to that is if you've disabled the serial port in Coreboot. In which case you can reset the Coreboot values to default by powering up with the reset button pressed: https://pcengines.ch/howto.htm#serialconsole However it's much more likely your terminal setup not correct. Try 38400baud or 9600. Steve

That is exactly the issue. It's funny you mentioned this as I was just in the process of opening up another browser and I saw this reply come in. It worked. For anyone else that may experience this issue, do as @Rico mentioned. It works. Cheers Rico. Solved!!

The problem is in the script "check_proxy_wpad.sh". His must edit, like so: #!/bin/sh status=$(/bin/ps -wx | /usr/bin/grep 'nginx-wpad.conf' | sed -e '/grep/d') if [ "$status" == "" ];then /usr/local/sbin/nginx -c /usr/local/etc/nginx/nginx-wpad.conf else exit 0 fi

You might run rehash after loading those so the command become available directly. Steve

If you assign things in a different order to start with, then the labels on the system won't align properly. But again, that does not matter in the long run. Use your own names and it won't be an issue. You haven't shown the full interface assignment list, so it's impossible to say what led to that situation. Either way -- Ignore the OPTx names and set your own custom names. The labels only reflect what is assigned out of the box in a default configuration. They do not have to be set that way, and typically will not match once a customer starts customizing their system.

Also: https://www.freebsd.org/cgi/man.cgi?query=rate&apropos=0&sektion=1&manpath=FreeBSD+11.2-RELEASE+and+Ports&arch=default&format=html It could well be related to the Traffic Graphs page where it shows flow info for IPs on that interface also. You might try using the traffic graphs widget instead which does not display that. Steve

It's actually been stable for the last week. I'm glad you mentioned that mine is a Netgear switch too so if it happens again I'll take care on that. Thanks all.

Hmm, Ok. So it sounds like the APs are in fact behind pfSense. Traffic from clients on wifi goes through pfSense and out on one of the new high speed WAN connections you have and not through the Cisco firewall. If doesn't really matter what path the authentication takes the captive portal doesn't manage that it manages traffic from the clients to the internet. It should be on whatever internal interface the APs are connected to. You will have to add pass rules to allow the APs to reach the cloud controller though. It also sounds like you don't want authentication on the APs at all. Clients have to login at the captive portal anyway. It does look like the Meraki APs support radius accounting so you could probably do limited connection time per user there directly but if you need to set bandwidth limits per user or use total data limits I think you would need to use a captive portal. This is not something that we often see though. Steve

Second version of the monitoring script. Now all static routes from config.xml are pushed to an array for main gateway, no script editing is needed except you have to set correct main and backup gateway names before the first run. gateway_monitor_v2.txt

What latency do clients see to the file stores? smb is notoriously terrible over high latency links. What speeds do they see if they try pulling files in some other way? SCP for example? I would still try enabling mss clamping in IPSec as a test. Steve

[image: 1560316933538-d5cc103f-5982-42b6-adb5-eeb94b28c82c-image.png] That's the Forwarder. As the image stated, it's deactivated. The Resolver ?

@tman222 - My apologies...I should have mentioned that if I did use Verizon's router, I was going to administrate/login to it and disable DHCP, etc. I just wasn't going to plug it in cold to the pfSense interface I would configure for it.

Yeah that's a mistake. Corrected. Not that I can think of. You can do a circular capture that keeps overwriting the older files but you can miss the event if you don't stop it soon enough after it happens. See if adding -p helps: nohup /usr/sbin/tcpdump -i eth0 -p -c 1000000 -s 0 -w /root/packetcapture.cap arp or port 67 &

First of all, you need to clarify if the pritunl VPN users (while connected) will be "going" out with their 192.168.22.x IP address , or with the IP address of the Pritunl network interface (192.168.226.1). Also, I assume that you have created a Server in the pritunl that assigns the 192.168.226.x IP addresses. In that server, you will have to add a route towards the 172.17.172.x network (see below) [image: 1560265449597-b7fc52a1-f8e5-4555-8671-6d04a35c5b5b-image.png] After you do the above, then you can start pinging from a VPN user towards your Servers. In order to see if the Pritunl VPN user is going out with its assigned IP addres (192.168.2226.2) and not with the Pritunl server IP (192.168.226.1), go to Packet Capture in pfsense and check the traffic on the pfsense interface that belongs to 172.17.172.x network. *I would create an alias for these VPN users and name it "OpenVPN_Users" (Alias type is network with an IP address 192.168.226.0/24). Then I would go to the firewall rules and I would add a rule to allow the OpenVPN_Users network towards the 102.17.172.0 network. Not sure if you have to configure the Advanced Settings on that rule, but if you still cannot ping the servers, you may have to go and change the TCP flags to "Any" and the State Type to "sloppy" (see below) [image: 1560264877380-4e012871-d683-4bee-a1e1-8e3c38a6307e-image.png] Also, I assume these VPN users will be having internet access via your pfsense, which means that they will be going to the outside world via the WAN interface. If so, maybe you would have to add a NAT rule, but check first if it works without any NAT rule.

I have not been able to reproduce the problem here, but I can see how it might happen. I opened https://redmine.pfsense.org/issues/9582 to track it and committed a fix: https://github.com/pfsense/pfsense/commit/45f95753963e497b5ce14493f9cca05336d75c7b You can install the System Patches package and then create an entry for 45f95753963e497b5ce14493f9cca05336d75c7b to apply the fix. Alternately, you can use viconfig to edit the config and remove that <vlans></vlans> line, or download a backup, edit it out, then restore.

Isolated the issue! During testing, I had misconfigured my cable-modem ISP. A hard reset of the cable modem and a switch back to DHCP on pfsense wan-1 interface cured the issue. Not sure how it was providing 50% connection, as everything was messed up.... :-) Full capacity restored!!

You could set a sysctl tunable for machdep.hyperthreading_allowed=0 if you didn't want to disable HT in the BIOS.

Ok it´s solved! As mentioned I canceled all ntp-relevant setups and build up this as new. Of course: it does´t work: my test-client did not syncronise with the running NTPd on pfsense. I found a little tuto which described how to configure such a setup. Nothing new at all but it says how one could test if it works. This test was new for me: stop the ntp-service on the client, give ntpdate 192.168.114.1 (which is the CARP-LAN-IP) and start the service again. The ntpdate says: "no server suitable for synchronization found". A rule for udp/123 from LAN to the FW is active. Than i checked some configs in the Switch between the FW and the VM-Host with the test-client. It was preventing "SYN/SYN-ACK Flooding". Made tests, checked it twice, problem was found. Thanks for all advices and hints. Fred

@MarekAndreansky said in pfSense goes silent, then resumes operation, repeatedly: Is there a way to test cabling via pfSense? As said : there isn't. But, as you know, you have a WAN and LAN. What about swapping cables If the problems move to a new interface - on WAN for example then you know that your problem is the cable. If it is the same interface, you know that you should focus on a that interface (NIC) - check both sides.