Hello,

as I cannot see any more the thread I started on friday I reinstalled
XANANEWS and redownloaded all postings from this thread. For the last 2
weeks I now have only a small part of the postings google-newsgroups is
listing.

Something wrong with the newsserver??


e.g. this thread I cannot find anymore:

--------------
Hello,

VPMASTER: BM3.6EE on NW6.0.5
VPSLAVE: BM3.6 from NW6.0SBiz, 6.0.4

The problem:

from the VPMASTER there is *effective* an odd route to the public IP
that goes through the VPTUNNEL. For VPMASTER RIP and OSPF is disabled,
so it is on the side of the VPSLAVE (no direct access for me to that
server, but the admin there sweares, that RIP and OSPF are disabled,
too).

in sys:etc/gateways for both servers are network routes to all networks
on the other side, so that from both sides all IP-Nets with private
IP-ranges (10.x.x.x, 172. ... and 192.168. ...) can be accessed, that
works nicely. On the VPMASTER's side there is especially no host route
for the VPSLAVE's pubIP pointhing towards the VPSLAVE's tunnel IP
Address.


From the slave's side an IPTRACE correctly goes to the VPMASTER's PubIP
listing all hops through the internet.

From the VPMASTER's side an IPTRACE *incorrectly* goes through the
VPTUNNEL (2 hops, 1st answer = the VPSLAVE's VPTUNNEL IP and 2nd answer
= the PubIP of the VPSLAVE)

The VPTUNNEL is up and stable, also reboots on both sides do not change
something. Both Servers are "UP and up-to-date" in NWAdmin->VPN-> ...


As neither RIP nor OSPF are active and there is no host route at the
VPMASTER's IP configuration I am wondering, where does that odd routing
through the Tunnel come from? And why doesn't this cause the tunnel to
break down for rewrapping the tunnel in the tunnel in the tunnel ... ?

And why doesn't happen the same vice versa?

What I would like to know next is to figure out, if this is due to a
malconfiguration on the master or on the slave side. A trace of the DMZ
traffic on the VPMASTER's site doesn't help to watch out for odd RIPs,
as that traffic is encrypted. In a TCP dump on the VPMasters side I
couldn't find such packets. So any suggestions what to check next?



Thanks, Rudi.

In article <Ynzxd.5897$Ei5.1629@prv-forum2.provo.novell.com>, Rudolf
Thilo wrote:
> from the VPMASTER there is *effective* an odd route to the public IP
> that goes through the VPTUNNEL.
>

This sounds very incorrect, and should be removed.

Check your protected network config in the VPN config. I don't see how
it could have been put there by the config, but check anyway.

If you take out this route, the next question is - do things work now?
And the question after that is - does that route come back by itself
after a VPN Synch All?

Craig Johnson
Novell Support Connection SysOp
*** For a current patch list, tips, handy files and books on
BorderManager, go to <http://www.craigjconsulting.com> ***


Craig Johnson wrote:

> If you take out this route, the next question is - do things work
> now? And the question after that is - does that route come back by
> itself after a VPN Synch All?


Well, I could not find at all such a route, so there is nothing I can
take out.

But I will check what a VPN Sync All will do. That one I didn't try
yet, and I couldn't get the VPSLAVE server rebooted, too.


Regards, Rudi.


Craig Johnson wrote:

> In article <Ynzxd.5897$Ei5.1629@prv-forum2.provo.novell.com>, Rudolf
> Thilo wrote:
> > from the VPMASTER there is effective an odd route to the public IP
> > that goes through the VPTUNNEL.
> >

> This sounds very incorrect, and should be removed.


Eh, really!! ;-) I was trying hard to find the place where this dumb
route comes from for hours... :-//

in sys:etc/ the *. files and *.cfg files look good to me. But I will
check again...

> Check your protected network config in the VPN config. I don't see
> how it could have been put there by the config, but check anyway.


I've been in there for the VPMASTER (that with the incorrect route to
the PubIP of the VPSLAVE), and saw, that the public IP of the VPSLAVE
*was* in the list of the protected networks. I removed it. After that,
the VPMASTER was rebooted twice, no change: IPTRACE to the pubIP of the
VPSLAVE shows as hop1 the VPTUNNEL IP of the VPSLAVE, as hop 2 the
pubIP of the VPSLAVE.

Tomorrow I will be at this site again. What I was wondering, if a
workaround might be to insert a host route:

VPMASTER, inetcfg, Protocols, Lan Static Routes, list, -> PubIP of
VPSLAVE/32, <ip-of-VPMASTERS-default-gateway>


Any other suggestions I should keep in mind tomorrow?


Thanks, Rudi.