Hi, I am running most recent net-next git tree version and compiled the xt_ipvs match extension for ipvs, here is the info: # uname -a Linux vincent-hp 3.10.0-rc6-ipvs-with-nat #3 SMP Wed Jun 26 21:19:32 PDT 2013 i686 GNU/Linux Module Size Used by xt_TRACE 726 0 xt_tcpudp 1895 0 iptable_raw 1162 0 xt_LOG 11066 0 arptable_filter 1122 0 arp_tables 9012 1 arptable_filter iptable_filter 1302 0 xt_nat 1746 2 iptable_nat 2646 1 nf_conntrack_ipv4 12368 1 nf_defrag_ipv4 1181 1 nf_conntrack_ipv4 nf_nat_ipv4 3487 1 iptable_nat ip_tables 10235 3 iptable_raw,iptable_filter,iptable_nat nf_nat 14458 3 xt_nat,iptable_nat,nf_nat_ipv4 xt_ipvs 1620 2 x_tables 15304 10 xt_TRACE,xt_tcpudp,iptable_raw,xt_LOG,arptable_filter,arp_tables,iptable_filter,xt_nat,ip_tables,xt_ipvs binfmt_misc 5844 1 ppdev 5120 0 ip_vs_rr 1643 2 ip_vs 148089 6 xt_ipvs,ip_vs_rr nf_conntrack 77550 5 iptable_nat,nf_conntrack_ipv4,nf_nat_ipv4,nf_nat,ip_vs libcrc32c 855 1 ip_vs root@vincent-hp:/usr/src/net-next# iptables -t nat -n -L Chain PREROUTING (policy ACCEPT) target prot opt source destination Chain INPUT (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain POSTROUTING (policy ACCEPT) target prot opt source destination SNAT all -- 0.0.0.0/0 0.0.0.0/0 vaddr 10.1.72.169 vport 80 to:10.2.72.139 SNAT all -- 0.0.0.0/0 0.0.0.0/0 vaddr 10.1.72.169 vport 22 to:10.2.72.139 # ipvsadm -L -n IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 10.1.72.169:22 rr -> 10.2.72.99:22 Masq 1 0 0 TCP 10.1.72.169:80 rr -> 10.2.72.9:80 Masq 1 0 0 -> 10.2.72.99:80 Masq 1 0 0 no any filter, mangle, raw iptable rules. the ipvs load balance works fine, but running tcpdump on LVS director and real server shows the client source address is not translated to specified address 10.2.72.139. I used TRACE target in raw filter to trace the packet, I saw the packet went through 'nat' table PREROUTING chain, not POSTROUTING chain. I am using LVS NAT mode. I have seen this issue before with previous kernel 3.6.x release, but not bothered to file report, it hasn't worked for me so I am wondering if I am missing something or there is bug in xt_ipvs match extension, any debugging tips or idea would be appreciated. I can post the tcpdump capture or debugging message with TRACE in raw table if needed Thanks -- 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
