Hi, Unless there are additional rules in a forward chain, which were not shown in your mail: > With these, the following packets are seen on eth-tls interface... > ...ICMP 16.15.192.246 tcp port 443 unreachable... ... > And at the same time, I see this in dmesg:... > Jul 03 10:13:12 gate kernel: tls->ext reject:... It appears that reject functions 'well' - an ICMP reject is sent; though, it should probably appear in dmesg - that is configuration task on your part. Whether you can aptly match this type of packet with expressions, I am unsure. After writing the rule to match ICMP reject, check the 'bytecode' by adding the '-d' flag to your call to 'nft' when loading the ruleset. Try '-d netlink', but '-d all' can be helpful if you have the time. > With these, the following packets are seen on eth-tls interface... > And at the same time, I see this in dmesg... It appears that the packet is not forwarded - try re-running the test after logging all packets to dmesg, and compare to output of something like tshark or wireshark. > And at the same time, I see this in dmesg:... > ul 03 10:13:12 gate kernel: IPv4: martian source 192.168.177.2 from 16.15.192.246, on dev eth-rinet It is possible that this log occurs prior to the packet getting dropped. You are correct in saying that it does not originate from address "16.15..." and it should not be on the 'rinet' interface. What a poor log! That code may have been written when only inbound filtering was popular. It may also (poorly) report that it was found on a different interface compared to where it really occurred, or, it really was forwarded to the wrong interface, and 'rp_filter 1' saved the situation. Try setting up some explicit rules to kill martian packets, where they should not exist. i.e. block 192.168.0.0/16 source out WAN, 192.168.0.0/16 destination from WAN (usually... -_-), etc. sunny
