Hello,
My issue is with linux routing tables using iproute2, coupled with the iptables MARK target. When I create a rule to lookup a table with iproute2, and the routing table routes an address as type unreachable (or blackhole, or prohibit), if a higher priority rule does a lookup to another table that routes the address as type unicast but that higher priority rule also matches on a fwmark, the packet to that address is never generated locally to even go through iptables packet filtering/mangling in order to mark it, because the lower priority rule that doesn't match on a fwmark says it's unreachable.

For example, I have 2 rules installed with ip:
ip route list table routeit
ip route list table unreach

Now, in the packet filter, I have an iptables rule to mark packets to destination 10.0.0.5 with 0x1000 in the mangle table and OUTPUT chain. When I generate a packet locally to 10.0.0.5, all programs get ENETUNREACH (tested with strace). However, if I take out the route entry that 10.0.0.0/8 is unreachable, it all works fine and the routes in the routeit table get applied to marked packets (I know because my default gateway would not be 1.2.3.4, but wireshark shows packets being sent to the MAC address of 1.2.3.4).

The best I can surmise is that when generating a packet locally, the kernel tests the routing tables in priority order but without any mark to see if it is unreachable/blackhole/prohibit, and doesn't even bother generating the packet and traversing iptables rules to see if it would eventually be marked and thus routed somewhere. Then I assume after that step, it traverses iptables rules, then traverses the routing tables again to find a route. So is there any way around this behavior besides adding fake routes to the routing table (e.g. routing 10.0.0.5 to dev lo in the unreach table in this example)?

Thanks

Try setting a suitable source address on the unreachable route, Linux uses the default routing table to work out which source address to use.

Thanks, I appreciate the reply. I tried that, but it still didn't work. I tried to trivialize the testcase as follows:

• 
  
  Code:

  # ip rule list
  0:      from all lookup local
  10:     from all lookup main
  30:     from all lookup gateway.excl
  50:     from all lookup gateway
  60:     from all lookup default

• 
  
  Code:

  # ip route show table gateway.excl
  unreachable 10.0.0.0/8  src 127.0.0.1
  unreachable 172.16.0.0/12  src 127.0.0.1
  unreachable 192.168.0.0/16  src 127.0.0.1

• 
  
  Code:

  # ip route show table gateway
  default via 192.168.0.1 dev eth0

• 
  
  Code:

  # iptables -t raw -A OUTPUT -d 10.0.0.0/8 -j ULOG --ulog-prefix 'UNREACHABLE TRAVERSING:'
  # iptables -t raw -L
  Chain PREROUTING (policy ACCEPT)
  target     prot opt source               destination
  
  Chain OUTPUT (policy ACCEPT)
  target     prot opt source               destination
  ULOG       all  --  anywhere             10.0.0.0/8          ULOG copy_range 0 nlgroup 1 prefix `UNREACHABLE TRAVERSING:' queue_threshold 1

• 
  
  Code:

  # ping 10.0.0.4
  connect: Network is unreachable

• My ulogd log file did not log anything. I knew it was working because when I removed the "unreachable 10.0.0.0/8 src 127.0.0.1" route from the gateway.excl table, I got a logged line:
  
  Code:

  Jul 10 21:24:20 spongebob UNREACHABLE TRAVERSING: IN= OUT=eth0 MAC= SRC=192.168.0.101 DST=10.0.0.4 LEN=84 TOS=00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=27393 SEQ=1

Sorry about being more verbose than necessary, but I want to make sure that this problem is more easily understood, and to provide a simpler testcase for anyone interested.

My current kernel is a 2.6.32 series, so I don't know if packets to unreachable routes can traverse iptables chains in a later kernel.

Thanks in advance to any replies.