Not beyond send notifications or don't in the current package.

Steve

You could also use 'fetch' which is included for future reference.

@marco-jaeger said in Firewall Rules with Alias only works after rebooting the pfSense:

Check this redmine ticket: https://redmine.pfsense.org/issues/9296

Still, the issue seems far less then 6 month ago - I tend to say : for me : no more issues.

@marco-jaeger said in Firewall Rules with Alias only works after rebooting the pfSense:

our pfSense (Version 2.4.4_P1)

@marco-jaeger : what about simply updating to p3 ? The problem will be probably be less - and don't forget the other problem : less other issues which some are security related.
The issue could not be 'filterdns' related, but more 'ipfw' - and this is based out of FreeBSD....

( I think I saw flying @bmeeks other palm now ^^ )

This has been going on for a few months now and is very likely a SYN-ACK flood, as opposed to a SYN flood.

The source IPs in the SYN packets are forged. Using forged IPs, the attackers can select any set of source (victim) addresses they want. Those victims are flooded with SYN-ACK packets.

Blocking the traffic will only be effective until they choose another victim, which they seem to do regularly.

Sadly, there really isn't much you can do. Search for "Anatomy of a SYN ACK attack". I'd post the link but Akismet is stopping me.

I expect a steam download will cause carnage.

I consider that the ultimate test, steam downloads (uncapped in client) are almost like DDOS'ing your own line 30+ download threads.

Basically when a line is saturated you will get packet loss, there has to be, TCP flow is controlled by the fact packets get dropped. However the issue is which packets are getting dropped and the amount been dropped.

Ingress shaping that prioritises small packets e.g. if working perfect would ensure these pings make it through on the monitoring, so presenting a loss free line, and "all" the dropped packets would be from the TCP downloads having practically no impact on throughput. That's the ideal world scenario.

It is a mystery why some people don't see this issue at all, some see it but can fix it via ingress shaping, others see it but cannot fix it at all (without a massive downstream throttle to prevent it). My theory remains a driver/nic issue been possible, but also hard to rule out the intermediate modem.

If possible the first test would be to swap out pfSense for something else temporarily, and if the behaviour is the same, then it suggests an issue either with modem or ISP side queuing. Certainly I think on the modern internet ingress is far more difficult to manage than egress, egress for me has only ever really compromised QoS in the days when it was tiny like on ADSL. Even then it tended to just skyrocket latency rather than cause significant packet loss. Buffer bloat is bad, but its a lesser evil than a mass of indiscriminate dropped packets.

There is always another option. :)

@stephenw10 Thanks

@stephenw10
Thank you so much Steve. Completely explains what I was observing. I just did a test and confirmed that it is working as expected. I also had an error with how I had configured DNS which was confounding things even more.

Basically there is no need for me to doing anything other than the default behavior. As long as the connections eventually end up going out the Comcast gateway all is good

Thanks!

Agree with @stephenw10 - there are few issues with just certain models of Intel cards, but overall they are pretty solid it. Chelsio support is also quite good for FreeBSD - which card are you using? Also, have a look at this link:

https://bsdrp.net/documentation/technical_docs/performance

Next time you see the interrupt storm messages occurring, try running "vmstat -i" from the command line to track down the culprit device (interface).

Hope this helps.

Thanks for the fast response!!

@NogBadTheBad Thanks, for support

Well it is up to the ISP device to provide reasonable support for a customer-owned firewall device while still providing the necessary IPTV, etc functionality.

That blog post is wrong (at least partially 😉 ). You should add that to /boot/loader.conf.local to avoid it being overwritten.

See our intructions for that here: https://docs.netgate.com/pfsense/en/latest/install/upgrade-guide.html?highlight=kern%20vty#upgrading-from-versions-older-than-pfsense-2-4-4

Steve

Yes, if you create a single interface bridge and use that as the VLAN parent you can set a MAC address for the bridge.

I've never tried more than one though.

Steve

I confirm. All virtual NICs were connected to one switch, this switch was not connected to physical NIC of course.

Now I have recreated the setup. Each virtual NIC is connected to separate virtual switch. Problem is gone.

Thank you for your help!

@johnpoz
ok, i didn't understand where to look.

but now i have new problem. the sg-1100 seems to have failed. i t seems to be completely dead. the pwr light comes on but none of the ports do anything. i tried connecting to the console via putty, no response. also it doesn't get warm any more.
i emailed support to see what to do.