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,

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

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.