On 15/4/20 10:11 am, Mike Everest wrote:
There are quite a few significant changes since 6.5! (especially security vulnerability patches ;)
Some things that may be related to your observations include automated hardware offloading to switch chip where supported, and some changes to the way fasttrack and connection tracking works. It is possible that your spoofed packets are detected as 'invalid'
The log do not report anything, and if I set firewall rules trying to match the packets they do not match.
(I see that Aaron has mentioned that too, while I was writing this :)
To test that possibility, maybe make a filter rule that matches invalid packets with source/dest address of known connections and see if it counts any packets?
They do not match. There not getting to the firewall level.
I don't entirely follow some points in your question though - in particular that pcap shows the packets but other packet capture does not... is there more than one router in this scenario? Perhaps you could describe the topology in more detail and how the various components are put together? :-}
Cheers!
Three ports. 1. Injection port 2. Customer LAN Side 3. WAN The filter box is using an external mirroring switch on the cable on port 2. The filter box injects the RST packets in to port 1 I used the packet capture feature to capture packets on ports 2 and 3 and test by access a filtered page. No RST packets in the capture. I did the test again but look at the port 1 only, try the blocked site again and this time there are RST packets in the pcap The router is silently dropping the RST packets, rp_filter is off and I tried with connection tracking disabled. I've dealt with the type of filtering box a number of times and never had an issue with a router filtering the packets out as long as the reverse path filtering was disabled. Thanks for any help Mike