On Tue, 30 Oct 2001, Kip Iles wrote:
> > 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.
> I tried setting up directorB with a tunl0 interface and can no longer get to
> directorB at all.
Why? What means "get to directorB" ? May be there is
tunl0/rp_filter protection in directorB. You should trace each step
of the path with tcpdump. There was thread one-two weeks ago on
such issue with TUN. Check the mail archive. The main requirements
- filtering in directorB should not drop the IPIP packets
- tunl0/rp_filter should be set to 0 (dangerous but who said that
GSLB with TUN is secure?). May be by using alternative routes (the
patches on my web page) you can achieve rp_filter protection even
for tunnel devices. Without altroutes I'm not sure, you have to
use other filters.
- the directorB's gateway should pass the replies to client
> One issue I am having difficulty comprehending is the interaction between
> VS-NAT, VS-TUN, and iptables.
> DirectorB uses iptables to setup a nat for all outbound traffic for it's
> realservers so they can DNS, Mail, etc. DirectorB also is configured as
> VS-NAT so inbound requests can get to the realservers and back out.
> DirectorB is the only router for its realservers. This all worked fine.
> Now, directorA wants to send an encapsulated packet to directorB. If I put a
> tunl0 interface on directorB pointing to the NAT address of the realserver,
> does ipip decapsulate before NATing?
Again, what is that: "pointing to the NAT address of the
real server". You should configure VIP somewhere on directorB and
then to create virtual service for it. There will be LVS-NAT real
server configured for this VIP. As result, directorA thinks that
directorB is a real server. OTOH, directorB after decapsulation
does not know that the packet was sent from directorA. So, you should
be able to deliver this packet to LVS (I didn't tried such setup).
> I would expect the packet exchange like this:
> or this:
> Am I totally lame on this?
Yes, this is correct. Now start tcpdump and check where is
the problem - in which step.
Julian Anastasov <ja@xxxxxx>