cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
7537
Views
0
Helpful
6
Replies

IPSEC in IPSEC Can it work???

David Williams
Level 1
Level 1

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.

6 Replies 6

david.tran
Level 4
Level 4

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.

Why would you assume that it won't work?

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.

Thanks!

I just tested this in my lab and it does seem to be working.  Mine setup is the same as yours with one exception:

- R1, R2 and R3 are cisco routers.  R4 is a Checkpoint firewall.  not enough routers in my lab environment

- I enable isakmp keepalive on R2 and R3

- setup an expect script to source ping between R2 and R3 to ensure the outter VPN tunnel is up and working

- I setup a Expect script to source ping between R1 and R4 VPN Peer to ensure that the "inner" vpn tunnel is working

That's great David!  Thank you!  Saves me the lab time so I can jump straight to debugging the live environment.  I will be sure to post the results.  Hopefully it is easy to pin down. 

Just out of curiousity, did you use tunnel mode, transport mode, or any combination of the two?

Thanks again!

I used the default setting which is tunnel mode.  With transport mode, this has to be explicitly defined in your "crypto ipsec transform-set"

All,

 

I have just been task to test this operation of IPSEC in IPSEC. How would one configure this? any assistance would be appreciated

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: