Given the lack of documentation I'm assuming this would not work, but I'm going to toss it out there to see if I can be proven wrong.
The sample network in the attached jpeg shows 4 routers (R1, R2, R3, R4), 4 private networks, and all the networks that make up the internet represented as the cloud.
The current configuration has R2 and R3 in place with a PTP shared key IPSEC tunnel built between them. A vendor for our client wants to place routers inside our customer's private networks and build up an IPSEC vpn between them. This would require that R1 and R4 to build up an IPSEC tunnel inside of the IPSEC tunnel that we have already built between R2 and R3.
I know there are most likely a dozen different ways this could be done better, but this is what our client is asking for and if we don't have to undergo a redesign to accommodate their vendor that would be really great, but redesign is always an option.
Look forward to any and all comments. Prove it wrong, prove it correct, or toss out new ideas. I'd love to hear it all.
yes, it will work. When 10.0.0.0/24 communicate with 10.1.0.0/24, it will trigger interesting traffics between 192.168.1.0/24 and 172.16.1.0/24 which will be a tunnel betwen R2 and R3, when then in turn bring up a tunnel between R1 and R4.
You may have to lower the MTU on R1 and R4 to avoid packet fragmentation.
Thanks David! Prior to this event I wouldn't have thought it would be a problem, but it fails for the client everytime the internal tunnel traffic fails over to the IPSEC backup path. When I searched for this on google I didn't get much and what I did get wasn't very encouraging. MTU has already been taken into account but it doesn't seem to be making any difference.
I started to wonder if the logic behind the processing of an IPSEC packet may be tied to protocol numbers indicating AH or ESP as payload, in which case I could see how this could fail during the unecryption process of the exterior tunnel provided it looked at the payload headers.
This is encouraging though, and warrants some lab time and some debug time to figure out what may be going on.
Login to the FXOS chassis manager.
Direct your browser to https://hostname/, and log-in using the user-name and password.
Go to Help > About and check the current version:
Check the current version availa...
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...