In no particular order:

• point to point GRE tunnels have to be symmetric, where each end is amirror image of the other. Otherwise the destination kernel willreject the inbound GRE packets, which makes sense from a securityperspective once you think about it.

• GRE tunnels require a local IP address before you can point routes atthem; I suspect that this is generic behavior and is so that the kernelknows what default origin IP address to put on packets going out throughthem.
• because GRE tunnels are network devices,

I normally expect IP tunnels to be opaque , that is to act as if theywere physical links: the packet is sent down one end and pops out theother end unchanged, just as if it went over a connection betweentwo routers, and the tunnel itself is indifferent to the details ofthe packets it is transporting. (The technical ISO way of describingthis is that I expect IP tunnels to act entirely as layer 2 entities.)

However, one of the peculiarities of GRE is that itis a translucent

I just got IPSec doing exactly what I need it to do. Unfortunately itturns out not to do me any good.

The problem is with tunnel mode IPSec, which has a cascade of issues.First, IPSec tunnels don't create actual network devices. This soundsharmless, except that you need a network device to establish routesand thus say things like 'network foo/24 is reachable over this IPSectunnel'.

IPSec deals with this with black magic involving Security PolicyDescriptors. If you add an