OK so everything is /24 and thus you have the same subnet at both ends on the tunnel. Hence, routing conflict with that iperf command and anything else sourced from the firewall itself.

Really you want those things is different subnets but because the remote WAN is using .132 you can't use /25 there.

I would try to set the gateway as outside the subnet. There's a setting for that in the advanced gateway settings: 'Use non-local gateway'

You can then set the remote WAN subnet to something much smaller, /32 even.

Then you can set the other IPs in a different subnet such as 185.113.141.208/28. You can add that as the static route on the remote pf and then use the IPs directly on the local pf.

The local pf LAN should use one of those IPs.

As an alternative to all of that you could just add all the IPs at the remote side as VIPs and then NAT the traffic to/from them and use private IPs at the local LAN.

Steve

@dennypage Hi Denny

Really great that you are willing to put this effort into providing more options with NtopNG on pfSense.

I already have a licensed NtopNG Enterprise Embedded running on a Raspberry Pi 4 collecting flows from Softflowd and a licensed nProbe Pro embedded I have (Portmirror on switch). I have been testing the difference between flows recorded by SoftflowD on pfSense and Nprobe Pro (portmirrored LAN to pfSense).
The difference is HUGE. NProbe does a lot of DPI analysis + records all DNS queries and fills alll that in as flow metadata to NtopNG. So in the UI you can the client sessions with domainnames instead of IP addresses and a lot of trafficanalysis of the sessions.
So it is much easier to dissect/analyze what happened in the nProbe flows than from SoftflowD.

I record this to a Clickhouse server on the same Pi. Runs great, and gives me 180 days history of all flows back in time.

I have decided to forego running the NtopNG package on pfSense as it cannot be licensed and work fully featured. I realize that one could perhaps avoid the licensing cost of a nProbe (And a port switchmirror) by setting up nTopNG like you suggested, but its a “heavy” package with lots of discwrites for nothing compared to nProbe. So I’ll stick with the nProbe Embedded as the deluxe flow generator, and look forward to testing the built-in pf flow exporter in 24.03 as the poormans flow solution.

But your work is still very much appreciated, and I’m sure it will be very well recieved in the community

@bmeeks
why the PHP shell i reach from menu point 12 does not give any hints?
All the examples given in the help commands don't work.

As this is the place, where I tested my scripts, I expected to get information about changes there.

Thanks for your link, I will dig from there.

It shouldn't be possible for anything external to reboot it. You might see a lo of logs or disconnections. Or potentially it could stop passing traffic entirely but it would still remain up. Or panic and log that.

@Gertjan How did you solve this error? I'm struggling with it on a couple of appliances

@stephenw10

Understood. Was more looking to follow his process and I would download manually and install

Because when you test from inside the firewall that traffic never hits the forwarding rules.

https://docs.netgate.com/pfsense/en/latest/recipes/port-forwards-from-local-networks.html

Tunables for FreeBSD will generally apply in pfSense but may not improve performance. On the page the default values should be fine for igc.

Well it would have to be a value that can be set in mpd5 since that's what the PPPoE server uses.

As a test you could try adding values to the conf file for the server in, for example, /var/etc/pppoe1-vpn/mpd.conf. You would need to manually kill the process and restart it like:
/usr/local/sbin/mpd5 -b -d /var/etc/pppoe1-vpn -p /var/run/pppoe1-vpn.pid -s poes poes

If you are able to find a value that works there most of that is created in /etc/inc/vpn.inc

Steve

@Patch yes, seeing the link for the earlier FR, I went to comment on that but couldn't as it was closed, hence the new FR with a link to the previous one. Not sure if that's the "right" way of doing it, but just wanted to bring it to their attention.
I'm hoping that if the new FreeBSD has it built-in, it requires minimal development on the pfSense side to include it as a feature - just a few Web UI tweaks?

Nice! Yeah we've seen ASPM cause all sorts of issues.

I found this post and this is exactly what I want to do. https://serverfault.com/questions/1034535/pfsense-dns-port-forwarding Instead of setting NAT reflection to Enable (Pure NAT) I tried setting Enable (NAT + Proxy) and I'm able to see result when I dig with my domain x.x.com. Unfortunately, I'm still unable to connect to DoT from my Android phone.

@stephenw10 Thank you @viragomann 's solution worked directly connecting to the firewall hardware console using video cable, keyboard and mouse.

Thank you again!

Ordering the Rackmount version shortly and I'll test restoring one component at a time to see if the interrupts persist, or at what point they may increase.

@stephenw10 unless they work for the ISP of the Feds.. Anyhow..

My fasting recipe
1/8 cup honey
1 banana
1/2 pint fresh blue berries
1/2 pint fresh red grapes with seeds
1 skinned Golden delicious apple no seeds
1/2 pint great value frozen fruit blend.
1/2 pint great value frozen tropical blend
top off with Eureka spring water,,
blend into a smoothie..

and get your crown on.. :)

Yes by default the server set in general settings don't do anything. pfSense resolves directly (Unbound in resolving mode) and clients are passed the local interfaces address to query against that.

Do you see blocked traffic in the firewall logs? Your rule probably isn't matching as you intended it to.

@JonathanLee - nope ... 2.7.2 CE from Dec of last year.

Hmm, as you say the llinfo arp messages have obscured anything that might give us a clue.

Really not much to go on there. The backtrace shows a general memory error but that could be hardware or software.

Is that the first time it has happened? Did it happen after upgrading to 23.09.1?

Yup use a static mapping: https://docs.netgate.com/pfsense/en/latest/services/dhcp/ipv4.html#static-mappings