----- Original Message -----
From: "Sven Schultheiß" <schultheiss,AT,steinbeis-europa,DOT,de>
> > Is there some reason the CIPE endpoints don't use the typical
> > 4-host subnet masks (255.255.255.252) that you would
> > see on a WAN PTP link? I'm having a little trouble understanding
> > how the route to the other end is found when the route table
> > entry has a netmask of 255.255.255.255 - but this does seem
> > to be working.
> 255.255.255.255 is a host netmask. An address with this netmask is one
> single computer.
> The endpoint of the tunnel is just a host. The Subnets behind that host
> have a own route with this host set as gateway.
I wasn't looking closely enough and thought the host address in the
route table was the local endpoint - or maybe I was looking at the
Win32 version where it does have a host entry for the local side
but then it also sticks in a class C for the other end.... On linux
the host entry is for the remote side, leaving the local side as the
magic one that doesn't show in the route table.
> > Also, are there any example configs where a firewall blocks
> > everything but the UDP tunnel packets but there is no
> > NAT involved and direct routes appear to exist to the
> > destination subnet?
> In the normal configuration, there shouldn't be any NAT on the Cipe
It does seem to work if there is NAT before it gets there as long as
the NAT gateway forwards to the right place. I think some of the
other tunnel mechanisms have trouble with that. If other routers
are involved, do people typically assign the CIPE host as the
default route, put static routes in the real router to bounce the
addresses back to the CIPE host, or run a routing protocol to
update the routers with the tunnel networks?