No worries. I remember hitting that issue myself when I first setup pfSense with multiwan. Too long ago to mention!

Until you realise how pfSense determines what is a WAN interface and what that triggers it can easily seem like magic. 😉

@w0w said in pfSense 5Gb/s Ethernet NIC:

@Craash
X710-T2L or T4L should support directly with latest firmware, but really don't know about FreeBSD and some OEM versions like Dell, have seen some 10/1 Gbe versions only.

Late to the party with this reply but you can flash the Dell versions of the X710-T2L and T4L to Intel firmware without too much hassle. This will enable the missing 2.5Gbps and 5Gbps speeds.

https://forum.level1techs.com/t/crossflashing-intel-official-firmware-on-dell-lenovo-pcie-x710-da2-nics-solved/196357/7

Little bit of reading but it works great. I used Linux but the tools are available for FreeBSD too. I've done a T4L and a T2L and both worked as expected.

@mcline said in After power outage netgate 4100 won't boot:

I was just googling when I cam up with the fsck command.

Youtube Netgate Official channel filecheck

For a file system check, the system needs to be unmounted = 'not actively used'.
When the system boots, the first menu, which times out pretty fast, offers you the option to do this check.

@mcline said in After power outage netgate 4100 won't boot:

Am I just screwed and my $700 FW is done because of a power outage or is there a way to replace the onboard storage and re-image it?

The 'good' news :
Disks die all the time.... whatever technology you use.
I have a 4100 also, and changing the disk isn't 'easy' but it is possible. The only sad thing is that it will be a ones in a live time experience, as you will probably stop using the build in nvme and shift to what is actually the MAX (SSD) version. Afterwards, statically, it won't be the drive anymore if something fails in our 4100..

@bozo-bogd said in OpenVPN slow download:

Hi everyone,

I'm facing another issue with slow downloads through an OpenVPN server.

Upload speed: 220 Mbps Download speed: ~40 Mbps Setup: pfSense 2.7.2 VM running on KVM with ample resources Connection: 600/600 Mbps line on both server and client

I've tested eight different server-side encryption parameter configurations without success.

Current settings:

Crypto engine: Enabled Checksum offloading: Disabled on both VM and KVM Fast forwarding: net.inet.ip.fastforwarding = 1 Custom OpenVPN config: tun-mtu 1500 fast-io mssfix 0 send/receive buffer tested with all possible values

Despite these optimizations, download speeds remain low.

Any insights or suggestions would be greatly appreciated!

Our experience is that without DCO enabled, OpenVPN is slow, even on relatively powerful hardware. This is OpenVPN's greatest limitation and is the primary reason we still use IPSEC for our site to site tunnels (though we are using OpenVPN for our client to site tunnels).

With DCO enabled on both ends, it's quite fast, at least in the site to site flavor (I would say in this mode it compares favorably to IPSEC. Probably around 90% of IPSEC's performance on average). Some of our appliances are running pfSense CE instead of Plus, however, and you have to have Plus to use DCO. Thus we use IPSEC.

Is this a client to site tunnel, or a site to site tunnel?

@crazily9892 said in OpenVPN Layer 2 with VLANs - How to Set Up?:

My pfSense lets me put a VLAN tag on my L2 VPN

Thank you.

I tried to set the VLANs on the OpenVPN tap interface:

Screenshot 2025-03-05 at 09.59.44.png

And then I added a bridge from the newly created VLAN to the existing interface which is tagged on the switch:

Screenshot 2025-03-05 at 09.59.48.png

Screenshot 2025-03-05 at 10.00.33.png

The CLOUD_LAN interface has a CARP Virtual IP Address:

Screenshot 2025-03-05 at 10.05.14.png

On the other end, I have a vmbr interface:

24: tap0.150@tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr150 state UP group default qlen 1000 link/ether e6:43:98:64:45:36 brd ff:ff:ff:ff:ff:ff 25: vmbr150: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether e6:43:98:64:45:36 brd ff:ff:ff:ff:ff:ff inet 192.168.150.1/24 scope global vmbr150 valid_lft forever preferred_lft forever inet6 fe80::e443:98ff:fe64:4536/64 scope link valid_lft forever preferred_lft forever

Which is bridged to the tap0 OpenVPN interface:

root@node1:~# brctl show bridge name bridge id STP enabled interfaces vmbr0 8000.107c614c4e64 no enp5s0 vmbr150 8000.e64398644536 no tap0.150

Anyway, if I try to ping the pfSense CLOUD_LAN IP address from the OpenVPN client, it does not work:

root@node1:~# ping 192.168.150.254 PING 192.168.150.254 (192.168.150.254) 56(84) bytes of data. From 192.168.150.1 icmp_seq=1 Destination Host Unreachable From 192.168.150.1 icmp_seq=2 Destination Host Unreachable From 192.168.150.1 icmp_seq=3 Destination Host Unreachable

And tcpdump only see the ARP request:

root@node1:~# tcpdump -i tap0.150 tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on tap0.150, link-type EN10MB (Ethernet), snapshot length 262144 bytes 10:03:23.636095 ARP, Request who-has 192.168.150.254 tell 192.168.150.1, length 28 10:03:24.659991 ARP, Request who-has 192.168.150.254 tell 192.168.150.1, length 28 10:03:25.683845 ARP, Request who-has 192.168.150.254 tell 192.168.150.1, length 28 10:03:26.708073 ARP, Request who-has 192.168.150.254 tell 192.168.150.1, length 28

This let me think that the problem is on the client, because packages are not exiting from it.

Do you have any idea?
Thank you!

Or wireguard. Or OpenVPN DCO.

@stephenw10
That was the DNS resolver configuration issue.
Outgoing Network Interfaces was set to "ALL".
I have changed it to "Localhost"
Decided not to use DNS Query Forwarding in the resolver.
Enabled DNSSEC Support.
Enabled Prefetch Support and Prefetch DNS Key Support.

All packages restored successfully.
Now I understand why my upgrade 2.6.0 to 2.7.0 was painfully slow.

@marcosm Oh yea, that error is definitely fixed by the patches. Thanks. I posted confirmation on that other thread in case someone else ran into it.

@sensewolf restart the gui

restart.jpg

And yeah if your using acme for your webgui - then that command @Gertjan shows should be in your acme client.

I don't have it because I don't use them in my gui, only for my haproxy stuff

guirestart.jpg

@tknospdr Yeah your fine this way - unless you worried about their warning ;) If so you could uncheck it and look into the other option.

For the sake of completeness for future search results...

I had an empty interface on my pf box so I brought it up as a separate subnet and moved my TrueNAS server onto it. I updated my firewall alias to point to the new IP address, pointed the other internal subnets' forwarding rules back to the alias, put my split horizon DNS rules back in place, and everything is working as it should.

I know it's academic now, but I'd really LOVE to find out what was causing my issues in the first place.

@patient0 yeah I would assume that a static mapping would override any deny, same goes if there is an existing lease already I would think.

@Bob-Dig Thanks Bob. The extra rules explained in the video did the trick.

@HeMan321 said in ntopng ignoring "Additional configuration for ntopng.conf":

But, to be honest, I am starting to realize that ntopng is probably somewhat too complex for my needs anyway. It is very slick and powerful, but I just wanted to keep an eye on outbound connections and so probably don't need to burden my Netgate box with everything else that ntopng does.

Smart choice.

@opticalc said in Netgate's openvpn client's remote server and my homes public IP:

and it was leaking DNS due to my client still using PFSense as the DNS server

Unbound (the pfSense resolver) can be forced to use the VPN connection also .....

@SteveITS What I meant by "one type of client device" is the following:

The customer has a number of application servers that provide a whole range of services. Their clients have devices that connect to their services. They recently updated their servers to a new major release and it seems the problem is that some clients, running an older version of the client software, were having trouble connecting to the new servers, which it turns out has nothing to do with the port forwarding at all.

@Bambos This is surely the case

@marcosm understood. i was just adding unsolicited feedback :)

It wouldn't be shown there. If it's anyway it will be in the main system log covering the boot up time or immediately after boot.

@LaUs3r When
I check logs (status > system logs > firewall) and see nothing relevant. I edit names and all personnal info (giving names can lead to security breach. in my opinion)