Hi Steve Apologies, been a bit busy the last couple of days. Just wanted to say thanks for the suggestions, I'll have a look at the CPU usage when we are seeing packet drops next and if I find anything definitive I'll update the thread.

@zenmasta typically windows defender gets picky about non-subnet traffic and blocks it... but not usually traffic from the same subnet. So if you're routing traffic you could look into how to expand the "home" networks that Defender will allow through.

Ok so to be clear you have all three pfSense NICs connected to the same switch? And it's an unmanaged layer 2 switch? You should be able to make that work. Mostly. But you will need to be sure you have outbound NAT rules in place to avoid asymmetry.

Try this: Create a virtual IP in the same network as your modem, in this example I'll use 10.0.0.1 as an example: Where you read MVNETA1, use OPT1. [image: 1667220357172-21afc87d-3859-4254-8f4a-a133318fe22a-image.png] Create an Outbound NAT, in this example I'll assume your LAN is 192.168.0.0/24: [image: 1667220477215-679fd839-79df-4488-8a88-d9aeda5484e3-image.png]

@rcoleman-netgate said in NET::ERR_CERT_AUTHORITY_INVALID PFsense web gui error: via an IP because signed certificates rarely have the IP address in their SAN That is why you can just create you own CA, and then your cert and trust the cert. With that you can use any fqdn you want, and any rfc1918 address as san.. https://forum.netgate.com/post/831783 I have posted how to do this multiple times over the years, here is one from 2019 above. before the browsers started getting picky about how long the certs were valid, you could do it for long time ;) [image: 1667184789892-cert.jpg]

@aberickson I have APC and use apcupsd with it.

You need a rule on LAN to allow that. You may also need to NAT that traffic because the AP probably has no default route in order to reply.

Easy fix for now.. go to- /usr/local/share/pfSense/pkg/repos/pfSense-repo.abi change "FreeBSD:14:amd64" to "FreeBSD:12:amd64" save.

Yes this is almost certainly because the hypervisor is not actually using VLAN5 for the interface linked to that VM so you actually need to untag it at the switch to make the connection. Which is what you were unintentionally doing by setting VLAN 5 as the 'native VLAN' for that port. So, yes, set the hypervisor interface to VLAN5 on NIC0 there. Unset VLAN5 as native for the switch port. Additionally you can probably choose to pass the traffic tagged to the VM in the hypervisor but you'd need to actually set VLAN in the VM then which you usually wouldn't do. Steve

@gme How did turn out? 8 years later... I'm looking at how best to integrate with New Relic.

@stephenw10 you are absolutely correct. That is why I consider this a work around and not a solution.

You probably need to use sudo for that. pftop is accessing some pretty low level stuff, you can't access /dev/pf even with admin permissions. Steve

I would use the main pkg unless you need something from the dev package package specifically. So something that's in HAProxy 2.5 and not 2.2. Steve

It looks like it isn't 192.168.1.248 because pfSense has that IP. So it doesn't match the traffic and the ping fails.

@fox95 said in help with Gateway/DNS configuration: i guess my question is, these are settings i never changed so why dont the defaults of pfsense out of the box work for me? Go here, and read the message at the top ;) Additional information : A resolver like unbound, used by pfSense, uses these root servers. The list with their host names and, more important, their IPv4 and IPv6 addresses, are build ('compiled') into unbound. These rarely (if ever) change. And if one doesn't answer, another is used. There are 13 of them, so pretty redundant. If pfSense (unbound) can't reach any of the 'root servers', you have a severe "connection to the Internet" issue. You can test that yourself : ping, using their IP addresses, them all.

Hi all, I posted the cause previously. The problem was simply that pfsense was not the default GW on the LAN. GW @ 10.0.0.1 pfSense @ 10.0.0.254 pfSense was set up in parallel to the existing GW so it could be configured to replace the existing GW. As pfSense was not the default GW none of the LAN traffic was being routed there and accordingly the modem GUI could not be accessed from the LAN. Simply adding a 2nd GW of 10.0.0.254 to the workstation, temporarily, allowed the modem GUI to be accessed.

@johnpoz I think bigger box would be fine .. keep in mind i virtualized pfsense vm on a server with 5GB of ram just for it anly 2 instances of suricata activated one on wan and other on one of my lan interfaces and that consumes about 3GB on normal and adding one more instance increase it to 4.5 and go to swap part :D

Ah, well a power cut would explain it!

@dobby_ thx Not long ago, the Odroid H3+ board was introduced. The positive thing is that the MB has 2x 2.5 GB NICs (Realtek, no Intel chip). CPU N6005 If I had known that 1GB of traffic could really handle it, I would have considered buying it. Odroid H3+

How are you testing exactly? What hardware are you using for pfSense? I assume the interface MTUs are all at least 1500? Steve