What's new

Reroute dropped packets

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

ml70

Regular Contributor
Packets to be dropped seem to end in filter INPUT to be discarded by the default drop rule, how to redirect them to a LAN ip to act as a catchall?
Could save some trouble every time a service changes ports, it's an outwards facing box anyway so receiving unwanted traffic is no problem, or to run a honeypot.

Something similar to
Code:
iptables -t nat -A PREROUTING -m state --state INVALID -j DNAT --to-destination 192.168.16.16
(seems the invalidity decision is also made by routing as the above rule still has 0 hits)
but how to re-dnat packets doomed by the routing decision?

Device is AC66 mips in case it makes a difference.
 
Last edited:
To partially answer my own question, unwanted incoming connections can be redirected at the NAT table after UPNP chain has been checked.

But it's still a mystery how to redirect packets which are deemed to be DROPped at the firewall (filter forward mostly). Even a modification of the firewall rules is ok if it can be done as a regexp replace.

But the original src ip address needs to be retained somehow?
If nat/redirect to localhost is the only answer, when nat happens I believe the kernel still internally holds the pre-nat address somewhere, but how to access that, or even rewrite it to the packet redirected to localhost?

Once I saw an advanced tc filter which could match outgoing traffic based on pre-MASQUERADE lan ip address, foolishly I did not save this, maybe it could be adapted to this case for incoming drop traffic.
 
Seems mangle table -j ROUTE could do this, just need to move all firewalling onto mangle table and s/DROP/ROUTE --options/ .
Any insights or experiences on this welcome.

Addition: this will cause the kernel to log the reason why the packets are invalid
Code:
echo 255 > /proc/sys/net/netfilter/nf_conntrack_log_invalid
 
Last edited:
Similar threads
Thread starter Title Forum Replies Date
K The Wireless 5GHz channel has dropped from 160Hz to 80Hz Asuswrt-Merlin 27

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top