Ipvsadm and netfilter

[Roberto Nibali]

Hello,

> According to LVS how-to, chapter 17.2, the path of an incoming packet
> should be:
> 
> PREROUTING -> LOCAL_IN -> POSTROUTING
> 
> But from what I can see, the path is more like
> 
> PREROUTING -> LOCAL_IN -> LOCAL_OUT -> POSTROUTING

I think the documentation is correct, but I would need to check the code 
first.

> The context;
> The director is connected on the LAN, 10.64.0.0/24, on its eth1 interface.
> Behind it, the real servers are on 192.168.76.2 on a 802.1q tagged
> vlan 3 and connected to the redirector on its eth0.3 interface.

So we have 10.64.0.0/24--->(VIP)eth1|LVS|eth0(DIP)--->192.168.76.0/24

> 10.64.0.16 is configured as an alias on the eth1 interface of the
> redirector, and the ssh port of this address is redirected to the ssh port
> of 192.168.76.2:
> 
> Ipvsadm rules:
> -A -t 10.64.0.16:ssh -s rr
> -a -t 10.64.0.16:ssh -r 192.168.76.2:ssh -m -w 1

Ok.

> Iptables rules: 
> Default policy fro all chains: ACCEPT

For all tables? How do you have LVS-NAT working then?

> -A INPUT -d 10.64.0.16 -i eth1 -j LOG --log-prefix "INPUT ipvsadm
> " --log-level 6 
> -A OUTPUT -o eth0.+ -j LOG --log-prefix "OUTPUT ipvsadm
> " --log-level 6 

For future make that '... -o eth0 ...' since no interface with the name 
eth0.+ exists (yes, I know what regex patterns are). To be completely 
sure of how your packets traverse the netfilter stack without reading 
the source code, I would add a LOG rule for all chains of the filter and 
nat table.

> If from the 10.64.0.0/24 lan I ssh to 10.64.0.16 packets go through the
> OUTPUT chain as you can see in my log:
> 
> OUTPUT ipvsadm IN= OUT=eth0.3 SRC=10.64.0.81 DST=192.168.76.2 LEN=60
> TOS=0x00 PREC=0x00 TTL=64 ID=3850 DF PROTO=TCP SPT=49851 DPT=22
> WINDOW=5840 RES=0x00 SYN URGP=0 
> 
> OUTPUT ipvsadm IN= OUT=eth0.3 SRC=10.64.0.81 DST=192.168.76.2 LEN=52
> TOS=0x00 PREC=0x00 TTL=64 ID=3851 DF PROTO=TCP SPT=49851 DPT=22
> WINDOW=5840 RES=0x00 ACK URGP=0 
> 
> OUTPUT ipvsadm IN= OUT=eth0.3 SRC=10.64.0.81 DST=192.168.76.2 LEN=52
> TOS=0x00 PREC=0x00 TTL=64 ID=3852 DF PROTO=TCP SPT=49851 DPT=22
> WINDOW=5840 RES=0x00 ACK URGP=0 

Looks rather normal.

> If I connect from another lan not directly connected to the director,
> the packets go through INPUT and OUTPUT.
> 
> INPUT ipvsadm IN=eth1 OUT= MAC=00:0a:5e:3d:82:0f:00:e0:1e:7f:98:61:08:00
> SRC=A.B.C.D DST=10.64.0.16 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=55012
> DF PROTO=TCP SPT=49852 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 
> 
> OUTPUT ipvsadm IN= OUT=eth0.3 SRC=A.B.C.D DST=192.168.76.2 LEN=60
> TOS=0x00 PREC=0x00 TTL=63 ID=55012 DF PROTO=TCP SPT=49852 DPT=22
> WINDOW=5840 RES=0x00 SYN URGP=0 
> 
> INPUT ipvsadm IN=eth1 OUT= MAC=00:0a:5e:3d:82:0f:00:e0:1e:7f:98:61:08:00
> SRC=200.9.208.76 DST=A.B.C.D LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=55013
> DF PROTO=TCP SPT=49852 DPT=22 WINDOW=5840 RES=0x00 ACK URGP=0 
> 
> OUTPUT ipvsadm IN= OUT=eth0.3 SRC=A.B.C.D DST=192.168.76.2 LEN=52
> TOS=0x00 PREC=0x00 TTL=63 ID=55013 DF PROTO=TCP SPT=49852 DPT=22
> WINDOW=5840 RES=0x00 ACK URGP=0 

:) Indeed, confusing. I don't know what's up with your setup but try my 
suggestion of adding a LOG statement for those tables and chains and no 
IP and try it again. It should be clear.

HTH and best regards,
Roberto Nibali, ratz
-- 
echo 
'[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc