> 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.
> 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
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.
----- Original Message -----
From: "Julian Anastasov" <ja@xxxxxx>
To: "Kip Iles" <kip@xxxxxxxxxxxxxxx>
Sent: Sunday, October 28, 2001 4:13 PM
Subject: Re: IPVS/FreeSwan - Freeswan broke IPVS