Just turn off IPv6 - does it work now? There you go you know where the problem is happening. But doing a directed query to 1.1.1.1 which wouldn't be IPv6 and getting a timeout just seems like bad connectivity, or slow connection, are you routing through a vpn? Are you on sat connection? You doing some odd redirection of dns traffic on pfsense? Do you have isp or other router in front of pfsense doing dns redirection?

It should be logged there if you have logging enabled on the pass rule(s) and any states have been opened. It may have left the logs already if you have a very busy WAN.

@bokolobs said in Anyrevo fanless appliance hitting >60 C, is this normal?: @nimrod I actually have an extra tube of Thermal Grizzly Kryonaut lying around. I might re-paste it if I feel adventurous. I would not do it. Although cheap, there is absolutely nothing wrong with your unit. All the issues you had so far were software issues. Just install pfBlockerNG, apply the patch and you are good to go. And thanks for the info regarding mini pc brands. This is my first unit like this. I'm used to assembling my own PCs, but I got lazy and just purchased this. It is also very difficult to get 4-port Intel NICs right now where I live. I still have a Beelink GK55 mini pc which I used as an Untangle box for almost a year, but it only had 2 Realtek ethernet ports and is no longer suitable for our network needs. I'll probably use this Anyrevo one until it breaks or gives me trouble. Or maybe I'll just build a low powered, mini-atx one with better specs if I can get my hands on Intel NICs. If you guys have recommendations, that would be awesome. Anyevo is a cheap appliance, but make no mistake. The board inside still has a Intel CPU and Intel NICs. Anyevo and other cheap Chinese brands, get lower prices by using lower quality metals for their case. Packaging is cheap. They have bad machining (rough metal), poor paint and printing on the case. They also ship their units with cheap AC adapters, cheap no name RAM and SSDs. There are no bios updates, software support, or any support for that matter. Warranty is also questionable. If you, for example, get higher quality power supply and better SSD, that unit will serve you for many many years with zero issues.

It looks like it's something in multicast routing though which is probably why more people are not hitting it. I don't see either IGMPproxy or pimd shown in your console output but do you have either configured? It could be same root cause as this: https://redmine.pfsense.org/issues/12079 It's very difficult to reproduce that issue unfortunately. Steve

Are you running that as TCP or UDP? It's hard to say from their website but it looks like it's UDP by default. That hardware should pass that without any difficulty at all. It could probably pass >5Gbps. I'd be amazed if this is not a restriction in the WAN some where. If you connect a client to the WAN directly do you see the expected 1Gbps with no loss? Does pfSense show packet loss in the WAN monitoring? Steve

@stephenw10 You sir are amazing! Thanks a bunch!!

@stephenw10 Ok, thanks!

@jimp I came across a post talking about this option. My configuration already had it disabled.

https://redmine.pfsense.org/issues/13388

There was a similar thread to this a few months back. User kept getting warnings from Hetzner about unregistered MAC addresses. It was a configuration issue though IIRC. As long as LAN side clients are sending all their traffic through pfSense anything on the WAN side cannot see the LAN side MACs. Since it's all virtual though Hetzner may be looking on the LAN side? Steve

@jarhead I have solved my Problems! I deleted everthing and started again several times! I have documented everything I did. Since it is a Word Document I've uploaded it to Dropbox, in case anyone is interrested here DropBox . Essentially I discovered that when I set up pfSense it connected to the DHCP Server in my ISP's Modem and gave it an IP Address on my WAN. I could not see why this needed changing so I left it alone and did not try to give it a static IP Address. I also think that when I had been asked during the pfSense installation process, when I was asked whether I wanted to enable a HTTP connection for WebConfigurator, I had answered "n", thinking that the alterantive would be HTTPS. This time I answered "y", and low and belhold I can now get into the WebConfigurator! Anyway, everything is now going and I no-longer have problems.

Check the logs. Unbound probably shows why it cannot start.

Of course FreeBSD supports multiple devices. pfSense is a firewall/router and was never intended to support multiple storage devices other than as a drive mirror. That's not to say it can't be done. If you search the forum there are multiple threads with users describing their own solutions for making it work. However all of them operate outside the default pfSense config such that if you need to reinstall and restore for example you need to be sure you can restore any custom scripting you added. It's far simpler to just install and boot from the larger drive directly. Steve

You could set the values very high since the other WAN is 100% down. So, for example, 1000ms latency and 80% packet loss. Really though you should tune the values to your connection. That's difficult to do if the cell is in very high use but you just want to avoid false alarms whilst still alerting if it goes down entirely. Steve

@stephenw10 Don't worry about it. It was Firefox with an adblocker but I hadn't seen that behaviour before with any other pfSense field. I'm not touching the pppoe config now that it's working.

@stephenw10 Aug 1 07:52:23 check_reload_status 402 Linkup starting bge1 Aug 1 07:52:23 kernel bge1: link state changed to DOWN Aug 1 07:52:24 check_reload_status 402 Reloading filter Aug 1 07:52:26 xinetd 76035 Starting reconfiguration Aug 1 07:52:26 xinetd 76035 Swapping defaults Aug 1 07:52:26 xinetd 76035 readjusting service 6969-udp Aug 1 07:52:26 xinetd 76035 service 19000-tcp deactivated Aug 1 07:52:26 xinetd 76035 19000-tcp: svc_release with 0 count Aug 1 07:52:26 xinetd 76035 service 19001-tcp deactivated Aug 1 07:52:26 xinetd 76035 19001-tcp: svc_release with 0 count Aug 1 07:52:26 xinetd 76035 service 19002-tcp deactivated Aug 1 07:52:26 xinetd 76035 19002-tcp: svc_release with 0 count Aug 1 07:52:26 xinetd 76035 service 19003-udp deactivated Aug 1 07:52:26 xinetd 76035 19003-udp: svc_release with 0 count Aug 1 07:52:26 xinetd 76035 service 19004-tcp deactivated Aug 1 07:52:26 xinetd 76035 19004-tcp: svc_release with 0 count Aug 1 07:52:26 xinetd 76035 service 19005-tcp deactivated Aug 1 07:52:26 xinetd 76035 19005-tcp: svc_release with 0 count Aug 1 07:52:26 xinetd 76035 Reconfigured: new=0 old=1 dropped=6 (services) Aug 1 07:52:27 check_reload_status 402 Linkup starting bge1 Aug 1 07:52:27 kernel bge1: link state changed to UP Aug 1 07:52:28 ppp 41093 Multi-link PPP daemon for FreeBSD Aug 1 07:52:28 ppp 41093 process 41093 started, version 5.9 Aug 1 07:52:28 ppp 41093 web: web is not running Aug 1 07:52:28 ppp 41093 [wan] Bundle: Interface ng0 created Aug 1 07:52:28 ppp 41093 [wan_link0] Link: OPEN event Aug 1 07:52:28 kernel ng0: changing name to 'pppoe2' Aug 1 07:52:28 ppp 41093 [wan_link0] LCP: Open event Aug 1 07:52:28 ppp 41093 [wan_link0] LCP: state change Initial --> Starting Aug 1 07:52:28 ppp 41093 [wan_link0] LCP: LayerStart Aug 1 07:52:28 ppp 41093 [wan_link0] PPPoE: Connecting to '' Aug 1 07:52:30 ppp 41093 PPPoE: rec'd ACNAME "nme-apt-bur-bras252" Aug 1 07:52:30 ppp 41093 [wan_link0] PPPoE: connection successful Aug 1 07:52:30 ppp 41093 [wan_link0] Link: UP event So either repluging in the WAN or going to Interfaces/WAN and disabling and reenabling the interface brings the WAN interface back online. I am not really seeing any difference from the failure before, maybe it is the network card. I am planning on building a new pfsense router soon so maybe that will resolve the issue as it does not seem to be a wide spread issue.

@eriksteel Please open a ticket at https://go.netgate.com/ and include the NDI, SN (if it's a Netgate device) and the order # for your renewal. Thanks!

@the-other Thank you! Yes these are the exact settings I needed. You are the best.

That CPU should pass 1G easily. Unless, perhaps, it's paired with bad NICs. What do you have there? At the command line run top -HaSP whilst testing the throughput. Is either CPU core at 100%? Are you running packages? Testing over VPN? Steve