I ran into an issue trying to route outgoing ipsec traffic from an ipsec responder hub that uses fwmark to route out a specific interface. The fwmark points to a route table that contains a default route out a specific interface. The fwmark is applied based on incoming interface of incoming traffic. I noticed that the mark was not being used when doing a route lookup. Is there any reason why this is? If not does this patch look reasonable? I just followed similar logic to how TOS was being used before route-lookup. I've only tested on an earlier kernel (3.14) and it works. Thanks!
Here's an example: The ipsec policy is simple, just a tunnel from 192.168.0.0/24 <--> 192.168.1.0/24 the ipsec hub is at 35.0.0.1 but when traffic is being responded too, instead of the expected interface (eth2) we end it out a different interface (eth0) route table: # ip rule list 0: from all lookup local 32766: from all lookup main 32767: from all lookup default 40000: from all fwmark 0x2 lookup 3 40000: from all fwmark 0x4 lookup 4 50000: from all lookup 3 # ip route 25.0.0.0/30 dev eth0 src 25.0.0.1 35.0.0.0/30 dev eth2 src 35.0.0.1 192.168.1.0/24 dev lan1 src 192.168.1.1 # ip route list table 4 default via 35.0.0.2 dev eth2 onlink # ip route list table 3 default via 25.0.0.2 dev eth0 onlink I noticed this in netfilter trace, traffic matches the ipsec policy: [ 85.910365] TRACE: mangle:PREROUTING:rule:4 IN=lan1 OUT= MAC=00:30:44:ff:b6:43:42:17:87:41:3c:eb:08:00 SRC=192.168.1.5 DST=192.168.0.5 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=35127 PROTO=ICMP TYPE=0 CODE=0 ID=15069 SEQ=1 MARK=0x4 [ 85.911895] TRACE: mangle:FORWARD:rule:2 IN=lan1 ***OUT=eth0*** MAC=00:30:44:ff:b6:43:42:17:87:41:3c:eb:08:00 SRC=192.168.1.5 DST=192.168.0.5 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=35127 PROTO=ICMP TYPE=0 CODE=0 ID=15069 SEQ=1 MARK=0x4
