SNAT / Masquerading problems using LVS-NAT

[Joseph Mack NA3T]

On Thu, 12 Apr 2007, Rudd, Michael wrote:

It seems no-one knows. I'm replying so you don't think we're 
ignoring you.

Julian, Horms,
 	Any ideas?

Thanks Joe

> After some more digging it appears this is related to the OPS or One
> Packet Scheduling feature. With the OPS feature turned off, the source
> IP address is correctly SNATed to my VIP. With the OPS feature on and
> working correctly(which we need for our UDP service), the source IP
> address isn't correctly SNATed.
>
> Is anybody aware of the code for this? I assume its related to not
> looking up the connection in the hash table anymore with OPS thus not
> SNATing. Maybe an iptables rule coudl fix this possibly?
>
> Thanks for any help
> Mike
>
> ________________________________
>
> From: Rudd, Michael
> Sent: Tuesday, April 10, 2007 3:10 PM
> To: 'LinuxVirtualServer.org users mailing list.'
> Subject: RE: SNAT / Masquerading problems using LVS-NAT
>
>
> Update has anyone seen this? I am basically seeing using LVS-NAT that
> the return packets are not being SNATed with the LVS directors VIP but
> have a source IP address of the realservers. I saw this work in the 2.4
> kernel but havent been able to make it work in 2.6. Any clues?
>
> Thanks
> Mike
>
> ________________________________
>
> From: Rudd, Michael
> Sent: Monday, March 19, 2007 9:10 AM
> To: 'LinuxVirtualServer.org users mailing list.'
> Subject: SNAT / Masquerading problems using LVS-NAT
>
>
> My current setup has 1 director and 2 servers behind it. Heres the dump
> from ipvsadm.
>
> [root at jackets-a sysconfig]# ipvsadm
> IP Virtual Server version 1.2.1 (size=4096)
> Prot LocalAddress:Port Scheduler Flags
>  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
> UDP  192.168.67.213:domain rr ops
>  -> dnsa-c:domain                Masq    1      0          110935
>  -> dnsa-d:domain                Masq    1      0          110934
> [root at jackets-a sysconfig]#
>
> LVS is working the way it should except return packets are not the
> correct source IP address. They should be from 192.168.67.213 which is
> the address of the service. Instead they are the address of the real
> server. This worked in kernel 2.4 when I tested it 2 months ago. Now its
> broken in my 2.6.18 kernel.
>
> Heres also a dump from ip addr. We are doing our dns traffic based on
> bond1.201.
> ...
> 8: bond0: <BROADCAST,MULTICAST,MASTER,UP,10000> mtu 1500 qdisc noqueue
>    link/ether 00:04:23:c5:63:fc brd ff:ff:ff:ff:ff:ff
> 9: bond1: <BROADCAST,MULTICAST,MASTER,UP,10000> mtu 1500 qdisc noqueue
>    link/ether 00:04:23:c5:63:fd brd ff:ff:ff:ff:ff:ff
> 10: bond2: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop
>    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
> 11: bond3: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop
>    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
> 12: bond0.200 at bond0: <BROADCAST,MULTICAST,MASTER,UP,10000> mtu 1500
> qdisc noqueue
>    link/ether 00:04:23:c5:63:fc brd ff:ff:ff:ff:ff:ff
>    inet 192.168.66.214/24 brd 192.168.66.255 scope global bond0.200
>    inet 192.168.66.244/24 brd 192.168.66.255 scope global secondary
> bond0.200
> 13: bond0.202 at bond0: <BROADCAST,MULTICAST,MASTER,UP,10000> mtu 1500
> qdisc noqueue
>    link/ether 00:04:23:c5:63:fc brd ff:ff:ff:ff:ff:ff
>    inet 192.168.2.104/24 brd 192.168.2.255 scope global bond0.202
>    inet 192.168.2.101/24 brd 192.168.2.255 scope global secondary
> bond0.202
> 14: bond1.201 at bond1: <BROADCAST,MULTICAST,MASTER,UP,10000> mtu 1500
> qdisc noqueue
>    link/ether 00:04:23:c5:63:fd brd ff:ff:ff:ff:ff:ff
>    inet 192.168.67.214/24 brd 192.168.67.255 scope global bond1.201
>    inet 192.168.67.213/24 brd 192.168.67.255 scope global secondary
> bond1.201
> [root at jackets-a sysconfig]#
>
> I've tried the ip_route_me_harder patch I found here
> http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.LVS-NAT.html#brow
> nfield but it doesnt appear to work correctly at least for me. Anybody
> got any clues as to what broke in 2.6 for this?
>
> Thanks
> Mike
> _______________________________________________
> LinuxVirtualServer.org mailing list - lvs-users at LinuxVirtualServer.org
> Send requests to lvs-users-request at LinuxVirtualServer.org
> or go to http://www.in-addr.de/mailman/listinfo/lvs-users
>

-- 
Joseph Mack NA3T EME(B,D), FM05lw North Carolina
jmack (at) wm7d (dot) net - azimuthal equidistant map
generator at http://www.wm7d.net/azproj.shtml
Homepage http://www.austintek.com/ It's GNU/Linux!