SNAT Confusion

[Rodre Ghorashi-Zadeh]

Hi Janusz,

Thanks for your response, I think I am getting closer.

>In theory, yes, but I can not see any way to do it on LVS director, neither 
>with Julian's conntrack patch (POSTROUTING nat not traversed, so netfilter 
>SNAT not working), nor my patch (works only for LVS-DR method).

I am using LVS-DR and not LVS-NAT. I tried this with your SNAT patch in 
place but it wasn't working, even though I could see the packets being 
SNAT-ed to the "token" ip address, both in the iptables counters and with 
tcpdump.

Also, I tried SNAT-ing the initial request from the realserver to a "token" 
ip address and used routing on the director in LVS-DR mode to send the 
replies back to the client/realserver (your recommendation #3) but this 
didn't work for me either. Could you explain this setup a little better? 
Thanks.

~Rodre


>From: Janusz Krzysztofik <jkrzyszt at tis.icnet.pl>
>To: Rodre Ghorashi-Zadeh <rodrico7 at hotmail.com>
>CC: lvs-users at LinuxVirtualServer.org
>Subject: Re: SNAT Confusion
>Date: Tue, 20 Mar 2007 12:49:51 +0100
>
>Rodre Ghorashi-Zadeh napisa³(a):
>>>You are right, the problem is probably related to source address matching 
>>>VIP configured on the director.
>>
>>This is what I initially thought so what I did was SNAT the source address 
>>(on the director) to be what I will refer to as a "token" IP address, in 
>>this case 101.101.101.101, and set the default gateway on the realserver 
>>to be the director, thinking that when the the realserver replies it would 
>>not now how to route to 101.101.101.101 and send it back to the director, 
>>which would have an entry in it's conntrack, and SNAT it back to the 
>>original address, which is the realserver:
>
>Yes, it sounds reasonable, but still does not solve the problem of director 
>dropping packets with source address matching one of its own addresses.
>>
>>realserver1 client (10.0.0.1:2777) -> director VIP (10.0.0.200:389) -> 
>>DNAT 10.0.0.200:389 to 10.0.0.1:389 and SNAT 10.0.0.1:2777 to 
>>101.101.101.101:2777 -> send packet to realserver1 service (10.0.0.1:389) 
>>-> director gateway IP 10.0.0.254 -> SNAT 10.0.0.1:389 to 10.0.0.200:389 
>>and DNAT 101.101.101.101:2777 to 10.0.0.1:2777 -> realserver1 client 
>>(10.0.0.1:2777)
>>
>To avoid confusion, I would describe this as below, using your "token" term 
>for realserver1 SNATed IP, DMAC and RMAC1 meaning director and realserver1 
>MAC addresses:
>
>1. realserver1 client: connect from RIP1:* to DMAC:VIP:389
>
>2. director: LVS-NAT VIP:389 to RIP1:389 and netfilter SNAT RIP1:* to 
>token:*, send to RMAC1:RIP1:389
>
>3. relaserver1 service: answer from RIP1:389 to DMAC:token:* (DMAC resolved 
>as MAC address of default gateway IP in your setup)
>
>4. director: LVS-de-NAT RIP1:389 to VIP:389 and netfilter de-SNAT token:* 
>to RIP1:8, send to RMAC1:RIP1:*
>>
>>In theory this should work, no?
>>
>In theory, yes, but I can not see any way to do it on LVS director, neither 
>with Julian's conntrack patch (POSTROUTING nat not traversed, so netfilter 
>SNAT not working), nor my patch (works only for LVS-DR method).
>
>Assuming you keep using LVS-NAT method, you could try to set up netfilter 
>SNAT of RIP1:*->VIP:389 to token:*->VIP:389 on the realserver itself and 
>teach the director where to find "token" (solution 3 from my prevoius 
>message). It sholud work without any IPVS patches.
>
>Janusz
>

_________________________________________________________________
Don’t waste time standing in line—try shopping online. Visit Sympatico / MSN 
Shopping today! http://shopping.sympatico.msn.ca