Double IPSec tunnel between routers

[franklaszlo]

I am facing with the following challange :

I have two routers and want to build two IPSec encapsulated tunnel between them, using SVTI interfaces.

The two tunnel interaces would have the same source and destination ip addresses in this case.

With one tunnel interface defined, it works well, however, as soon as the second tunnel interface gets defined, the first goes down.

Here is a sample configuration :

interface Tunnel0
ip address 192.168.1.1 255.255.255.252
tunnel source Serial1/0
tunnel destination 10.1.1.6
tunnel mode ipsec ipv4
tunnel protection ipsec profile ipsecprofile
!
interface Tunnel1
ip address 192.168.1.5 255.255.255.252
tunnel source Serial1/0
tunnel destination 10.1.1.6
tunnel mode ipsec ipv4
tunnel protection ipsec profile ipsecprofile
!

Actually, the case is rather a conceptual question than a live one. What is the root cause, that such a configuration is not working ?

ESP protocol distinguishes between ESP SAs endponits based on SPI identifier as well, doesn't it ? If yes, then whats wrong here ?

Thanks in advance...

[Shrikant Sundaresh · Accepted solution]

Hi Frank,

As a rule you cannot have two tunnel interfaces with the same tunnel source (serial 1/0), and tunnel destinations(10.1.1.6); using the same tunel mode(ipv4).

The work around for this would be to bounce one of the tunnels off a loopback interface.

So tunnel 1: tunnel_interface_1 --- serial 1/0 ---- internet --- 10.1.1.6

and tunnel 2: tunnel_interface_2 ---- loopback --- serial1/0 --- internet --- 10.1.1.6

This way both tunnels can be up at the same time.

Hope this helps.

-Shrikant

P.S.: Please mark the question answered, if it has been resolved. Do rate helpful posts. Thanks.

[franklaszlo]

Hi Shrikant,

thanks for your quick answer. Using loopbacks is indeed a solution and therefore I marked your answer as correct, however, I am still missing the root cause why the original configuration is not working.

As I mentioned, my question intended to be a conceptual one, that is : Is this an IOS limitation, a "just because" rule or there is some deeper, technical limitation that prevents it from working ?

Thanks,

Laszlo

[Shrikant Sundaresh]

Hi Laszlo,

I tried to do some research on the subject, and you could test the following if possible:

The link http://www.cisco.com/en/US/docs/ios/12_3t/12_3t14/feature/guide/gtIPSctm.html says:

Tunnel Protection

The shared keyword is not required and must not be configured when using the tunnel mode ipsec ipv4 command for IPsec IPv4 mode.

However, when the source of multiple tunnels is the same, all must share the same tunnel protection profile.

You could try adding the "shared" keyword to one of the interfaces, and see what happens, if it is a test setup.

However, if we need to get to the root cause, of why the shared keyword shouldn't be configured, I think only a developer would be able to tell us the restrictions they faced. If I do find anything though, I shall remember to post it here.

-Shrikant

[franklaszlo]

Hi Shrikant,

thanks again for your research. Actually, the shared keyword was not configured, unless it is a default setting and must be explicitly disabled, but I could not find it out until now. Both tunnels were using the same ipsec profile, however. It is a test setup, so I will try adding the shared keyword, I am cuorious what is goning to happen.

Anyway, I believe I have to be satisfied with the fact, that a loopback must be used as an endpoint in this case.

Regards :

Laszlo