On Thu, Nov 5, 2009 at 8:44 AM, Jari Laurila <jari.laurila@xxxxxxxxx> wrote: > On Wed, Nov 4, 2009 at 2:27 PM, Patrick McHardy <kaber@xxxxxxxxx> wrote: >> Jari Laurila wrote: >>> On Tue, Nov 3, 2009 at 8:54 AM, Jari Laurila <jari.laurila@xxxxxxxxx> wrote: >>>> Don't anyone have any clues for the problem I sent to the list on sunday? >>>> >>>> I find it really strange that decrypted packets coming from ipsec >>>> tunnel with destination address xx.xx.xx.42 are sent through interface >>>> ext1 even though ip -s route get xx.xx.xx.42 says that packet should >>>> go through interface ext0b. Ipsec tunnel itself is going through >>>> inteface ext1 but shouldn't packets get routed after they come from >>>> tunnel? I even tried to look at kernel code to figure out why this >>>> happens but I don't know enough about kernel and my c skills are a bit >>>> lacking, so I couldn't find the cause. >>>> >>> >>> Update Netfilter sees packet at mangle table in PREROUTING chain (I >>> added LOG rule), but nat table does not see the packet. >>> >>> I also have fwd policy defined for the connection in question: >>> >>> src srcip.srcip.srcip.secip/32 dst dstip.dstip.dstip.42/32 >>> dir fwd priority 0 >>> tmpl src gwip.gwip.gwip.gwip dst remgw.remgw.remgw.remgw >>> proto esp reqid 0 mode tunnel >> >> Try adding a TRACE rule to see how the packet traverses the netfilter >> hooks. >> > I did that. Here are the results: > > kernel: TRACE: raw:PREROUTING:policy:2 IN=ext1 OUT= MAC=xxx > SRC=remote_server DST=xxx.42 LEN=40 TOS=0x00 PREC=0x00 TTL=55 ID=43368 > PROTO=TCP SPT=21 DPT=1261 SEQ=4137897325 ACK=3664330034 WINDOW=65535 > RES=0x00 ACK RST URGP=0 > kernel: TRACE: mangle:PREROUTING:rule:1 IN=ext1 OUT= MAC=xxx > SRC=remote_server DST=xxx.42 LEN=40 TOS=0x00 PREC=0x00 TTL=55 ID=43368 > PROTO=TCP SPT=21 DPT=1261 SEQ=4137897325 ACK=3664330034 WINDOW=65535 > RES=0x00 ACK RST URGP=0 > kernel: TRACE: mangle:PREROUTING:rule:12 IN=ext1 OUT= MAC=xxx > SRC=remote_server DST=xxx.42 LEN=40 TOS=0x00 PREC=0x00 TTL=55 ID=43368 > PROTO=TCP SPT=21 DPT=1261 SEQ=4137897325 ACK=3664330034 WINDOW=65535 > RES=0x00 ACK RST URGP=0 > kernel: TRACE: mangle:sanitychk_acl:return:38 IN=ext1 OUT= MAC=xxx > SRC=remote_server DST=xxx.42 LEN=40 TOS=0x00 PREC=0x00 TTL=55 ID=43368 > PROTO=TCP SPT=21 DPT=1261 SEQ=4137897325 ACK=3664330034 WINDOW=65535 > RES=0x00 ACK RST URGP=0 > kernel: TRACE: mangle:PREROUTING:policy:13 IN=ext1 OUT= MAC=xxx > SRC=remote_server DST=xxx.42 LEN=40 TOS=0x00 PREC=0x00 TTL=55 ID=43368 > PROTO=TCP SPT=21 DPT=1261 SEQ=4137897325 ACK=3664330034 WINDOW=65535 > RES=0x00 ACK RST URGP=0 > > > Mangle chains policy is accept: > # iptables -t mangle -vnL PREROUTING > Chain PREROUTING (policy ACCEPT 46M packets, 21G bytes) > ... > Other rules > ... > Gah.. I feel really stupid right now :| My ipsec-tools.conf had typo I didn't notice until I read the confs hundredth time: I had lines spdadd xx.xx.xx.42/32 aa.aa.aa.aa/32 any -P out ipsec esp/tunnel/yy.yy.yy.yy-bb.bb.bb.bb/require; spdadd aa.aa.aa.aa/32 xx.xx.xx.42/32 any -P in ipsec esp/tunnel/yy.yy.yy.yy-bb.bb.bb.bb/require; and the correct lines were spdadd xx.xx.xx.42/32 aa.aa.aa.aa/32 any -P out ipsec esp/tunnel/yy.yy.yy.yy-bb.bb.bb.bb/require; spdadd aa.aa.aa.aa/32 xx.xx.xx.42/32 any -P in ipsec esp/tunnel/bb.bb.bb.bb-yy.yy.yy.yy/require; Still I think kernel should have better logging in situations like these. I found absolutely nothing from logs when i investigated why my setup failed... Thanks anyway.. I hope I didn't waste too much of your time :) -- 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
