Oops, I get it. SP does not catch multicast address in this case. Sorry about that. On 2/18/09, Jianqing Zhang <arrow.jianqing@xxxxxxxxx> wrote: > Yes, that is also what I thought. > > However it does not work in my test. > I add a SNAT rule on the host of 192.168.1.20 as following: > > iptables -t nat -A POSTROUTING -p udp --dport 5002 -o eth0 -j SNAT > --to-source 192.168.1.55 > > to change the source address of outgoing upd packets with port 5002 to > 192.168.1.55. > > I also insert one SPs as follows (output of "ip xfrm policy list"): > > ... > src 192.168.1.55/32 dst 192.168.1.21/32 > dir out priority 2080 ptype main > tmpl src 192.168.1.20 dst 192.168.1.21 > proto esp reqid 16409 mode tunnel > ... > > Then I send udp multicast at the port 5002. > > But, I cannot see any ESP packets by tcpdump. Furthermore, on the > recipient side, I can get the muliticast udp with the changed source > IP (192.168.1.55). Actually I have stopped IPsec on the recipient > side. It looks that IPsec on the sender side is bypassed. Do I miss > something? > > Thanks > > > On 2/18/09, Jan Engelhardt <jengelh@xxxxxxxxxx> wrote: >> >> On Wednesday 2009-02-18 17:17, Jianqing Zhang wrote: >> >>>If I configure both IPsec SPs and iptables, when an IP packet is going >>>out or coming, which will process the packet first? SP or iptables >>>(netfilters) rules? >> >> On the input path, obviously ESP is the first one seen, then the unpacked >> one; >> on the output path this is precisely reversed. >> > -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
