Wondering if I could get some insight from the expertise of the list involving kernel generated ICMP packets on a router _WITHOUT_ the use of NAT. I have router connected to three public netblocks. 1.1.1.0/28 Network #1 (eth1) Uplink #1 2.2.2.0/28 Network #2 (eth2) Uplink #2 3.3.3.0/24 Network #3 (eth3) Public Stub Network Currently I am using multiple kernel routing tables and iptables fwmark to enable the routing between all the networks/interfaces, I am not relying on the main routing table at all at this point. TCP/UDP work just fine. The problem I am currently experiencing is in relation to the ICMP packets generated by the kernel of the router and directing these packets to exit out the network/interface which the original packet entered. (maybe I shouldn't care so much? I would prefer not to have a default route in the main table.) Running a traceroute from a host on the Internet (5.5.5.5) to 3.3.3.3, the packets ingress path trough the router is 1.1.1.1 (eth1), ICMP (time-exceeded) gets generated by the router (kernel) and seems to go straight to the main routing table, and use the routers default gateway (currently not set). ICMP messages fail.. What is the best practice (if there is one) for matching kernel generated ICMP (related) packets and getting them to use a different routing table/egress path? I seem to be able to do this reliably with netfilter and TCP/UDP, but ICMP seems to be a different beast. My options seem to be afaik: #1. Somehow mark all inbound traffic by fwmark for ingress interface, then match related ICMP traffic, restore the fwmark, and use it with a custom routing table for egress. (ICMP seems to be sourced from 0.0.0.0 and hits the route table before netfilter OUTPUT?) Im pulling my hair out ;) #2. Use multiple next-hops for a default gateway on the router (main table). One for each network uplink I have. Not sure what effect this has if one of the routers link die (no DGD). I assume 1/nth of my ICMP traffic goes through. #3. Just use one of the networks as the default gateway for the router. (seems less than optimal for redundancy sake) #4. ??? Something else im not thinking/aware of. Any thoughts/ideas appreciated. Thanks -Mike -- Michael Vallaly <netfilter@xxxxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
