I was looking at Glendale Alpha2 and GRE tunnels.
So basically I have three sites with three Glendales: R1, R2 and R3.
A quick hub and spoke architecture R2 is the hub and R1 and R3 the spokes.
There are two situations:
- R1, R2 and R3 connected to the same subnet
- R1, R2 and R3 connected through a router R4(another Glendale)
I've setup the GRE tunnels with OSPF.
That was easy and it's working nicely in both situations.
The routing table is fine and I have connectivity.
Obviously I want to protect the GRE tunnel with IPsec.
And this does not appear to work.
For the local and remote subnet I have used the local and remote GRE tunnel endpoints, X.X.X.X/32 (basically I have followed pretty much the same steps I use with Cisco routers).
The IPsec interface was the eth0(external interface, like with the newer Cisco IOS).
In situation a) it's working.
In situation b) it's not working.
Looking at the routing table I've noticed a Kernel route to the remote endpoint tunnel, saying that X.X.X.X/32 is directly connected.
And a lot of ARP messages sent from the local external interface to the remote tunnel endpoints.
Of course in situation a) that's not a problem since they are in the same subnet.
But in situation b) that's a problem.
It appears that the Kernel route is causing troubles, and Glendale thinks that the remote endpoint is a local one (the ARP messages).
Actually I can see, depending how I synchronize the commit command, the IKE MM and QM negotiation going fine.
But as soon as that route appears, ARP messages will start to flow.
And the traffic does not follow the normal path.
So I was wondering if this scenario works with Glendale or if I've used a wrong approach.