Re: IPVS/FreeSwan - Freeswan broke IPVS

To: Kip Iles <kip@xxxxxxxxxxxxxxx>
Subject: Re: IPVS/FreeSwan - Freeswan broke IPVS
Cc: <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
From: Julian Anastasov <ja@xxxxxx>
Date: Mon, 29 Oct 2001 12:31:22 +0200 (EET)

On Sun, 28 Oct 2001, Kip Iles wrote:

> > We never tried FreeSwan together with IPVS but in any case the
> > exact Linux, IPVS and FreeSwan version numbers will be helpful.
> Sorry, I knew better than that ....
> Redhat Linux 7.1 with Kernel Patch 2.4.13
> FreeSWan 1.91, IPVS Version 0.9.5, ipvsadm 1.20-2


> > It could be mostly design problem but it is interesting to
> > catch it. If this is Linux 2.4 then IPVS does not fit fully into
> > the Netfilter infrastructure but for now it works with the NAT and
> > conntrack code together.
> I guess I am not far enough into it, yet, to understand this statement,
> fully. I am not using Netfilter on these boxes since I do my filtering with
> other routers. I did assume that IPVS used the Netfilter structures to
> create the NAT connections and that this pretty much filtered out anything
> not being handled by IPVS.

        IPVS uses only the netfilter's hooks. It uses own connection
tracking and NAT. You can see how LVS fits into the framework in this
may be already old document:

        Sorry, in home I have the latest version. May be the only
difference is that instead of nfmark the nfcache field is used to
mark the packets as IPVS property to avoid netfilter mangling them
in post routing.

> > I don't understand. The IP configured as real server in TUN mode
> > should run tunl device to decapsulate the traffic. Then may be any
> > NAT can take place but I'm not sure what is the goal.
> All the servers behind directorA route out via our main router and I had
> anticipated moving some of the servers to a remote location so I configured
> VS-TUN for them all. That has worked fine since the realservers can route to
> the client directly. The remote site has directorB and the realservers can
> only route to the client via directorB, so I decided to use VS-NAT since it
> is easier and all traffic must pass through directorB, anyway.
> My question is really this ...
> If directorA redirects a packet to directorB using VS-TUN, does directorB
> need to have a tunl interface. The realserver behind directorB is currently

        Yes, the host where the packets are destined (used as real
server IP in directorA) needs a tunneling interface. In your case this
is directorB.

> handled by VS-NAT. This really had nothing to do with the VPN issue.
> > I'll think on your setup but please provide the versions used.
> Thanks! I appreciate that.


Julian Anastasov <ja@xxxxxx>

<Prev in Thread] Current Thread [Next in Thread>