(How to) configure multiple site-to-site tunnels such that modifications to one will not affect the operation of any other

[bbrowncisco]

I have a 7206 router with multiple static site-to-site VPN tunnels to partner companies.  Each of these companies needs their own secure encrypted traffic and using DMVPN is not an option.  Currently, all tunnels are defined in one crypto map and the crypto map is applied to the physical outside interface on the 7206. There is an FWSM between the 7206 and the Internet.  I am testing with a 2811 router as the other tunnel endpoint across the Internet.

What I would like to do is be able to make modifications to any of the tunnels, add new tunnels, and delete tunnels without affecting the operation of any of the other tunnels.

My first thought was to create tunnel interfaces on the 7206 using private point-to-point addresses with the other point residing on the FWSM, create a static translation on the FWSM pointing to the tunnel interface, and configure the tunnel interface with the crypto map normally applied to the physical interface, (with the addition of adding tunnel source and tunnel destination commands).

Network 1.1.1.1/24 ---- VPN HUB 7206 ----  FWSM ---- Evil Internet ---- VPN Spoke 2811 ---- Network 2.2.2.2/24

                                             |____ Static Site-to-Site VPN Tunnel ___________|

7206 IOS Version: 12.4(22)T

2811 IOS Version:  12.4(19b)

This doesn't work, though.  When I initiate interesting traffic from a network behind the 7206 the router seems to drop the packet.  There is no log message whatsoever.  When I initiate traffic from a network behind the 2811 I see lots of log messages.  The 2811 begins Phase1 negotiation but an error indicates that the policies don't match.  On the 7206 the error is more descriptive, indicating that the local address is invalid.  NAT traversal is enabled by default and I see in the logs that the private address is found.

I opened a TAC case and the response was that crypto maps can only be applied to physical interfaces, not loopback, or tunnel, and I'm assuming not sub-interfaces either.  What I don't understand is why.

Can someone please help me to determine the best solution to use for hosting multiple site-to-site VPN's such that modifications to one will not affect the operation of any other tunnel?

Thank you in advance,

Bill

[Jonn cos]

Dear Bill,

If you want different tunnels for each client then why dont you take tunnel protection in consideration ?. You can define interesting traffic and can have control as to which traffic gets encrypted and which not. In that case you will have a dedicated tunnel and profiles to play without disturbing any other clients tunnel/confguration.

One advantage of using tunnel protection over crypto map is avoidance of administrative overhead found in latter configuration.

Let me know if this works.

[bbrowncisco]

Hi John,

Thanks for your reply.  Could you explain how interesting traffic is defined in your example?

Also, the remote termination point may not be Cisco equipment.  The tunnels are connected with other companies and we have no control over what kind of equipment they use.  We have always had to match our ACL's in the past, (opposite in syntax).  So in my test scenario I think I need to use a crypto map on the remote end.  How will that work with using a tunnel interface, even using tunnel protection?

I gave it a try anyway and I am receiving the same error as before, "invalid local address" followed by the IP of the tunnel interface.  For your reference I will copy my configs and log message below:

7206

====

crypto isakmp policy 5
encr 3des
hash md5
authentication pre-share
group 2

crypto isakmp key address 0.0.0.0 0.0.0.0 no-xauth

crypto isakmp invalid-spi-recovery
crypto isakmp keepalive 10 3

crypto ipsec security-association replay window-size 1024

crypto ipsec transform-set esp-3des esp-md5-hmac
mode transport

crypto ipsec profile
  set transform-set
  set pfs group2

interface Tunnel252
ip address 10.10.10.1 255.255.255.0
ip mtu 1400
tunnel source GigabitEthernet0/1
tunnel destination <2811_pub_ip>
tunnel protection ipsec profile

ip route 2.2.2.0 255.255.255.0 Tunnel252

interface Vlan5

ip address 1.1.1.1 255.255.255.0

FWSM

=====

static (inside,outside) 10.10.10.1 netmask 255.255.255.255

(ACL allowing VPN traffic between routers)

2811

===

crypto isakmp policy 10
encr 3des
hash md5
authentication pre-share
group 2

crypto isakmp key address
crypto isakmp invalid-spi-recovery
crypto isakmp keepalive 10 3

crypto ipsec security-association replay window-size 1024
crypto ipsec transform-set TEST_SET esp-3des esp-md5-hmac

crypto map TESTMAP 10 ipsec-isakmp
set peer <7206_pub_ip>
set transform-set TEST_SET
match address TESTMAPACL

interface GigabitEthernet1/0
no switchport
ip address
crypto map TESTMAP

interface Vlan5
ip address 2.2.2.2 255.255.255.0

ip route 0.0.0.0 0.0.0.0

ip route <7206_pub_ip> 255.255.255.255

ip access-list extended TESTMAPACL
permit ip 2.2.2.0 0.0.0.255 1.1.1.0 0.0.0.255

===============================

I initiate an extended ping from the 2811 using Vlan5 as my source interface to 1.1.1.1 and see this line in the log on the 7206:

Mar 26 10:30:18: IPSEC(ipsec_process_proposal): invalid local address 10.10.10.1

Mar 26 10:30:18: ISAKMP:(1084): IPSec policy invalidated proposal with error 8
Mar 26 10:30:18: ISAKMP:(1084): phase 2 SA policy not acceptable! (local 10.10.10.1 remote <2811_pub_ip>)

Even if it were valid in this case, how do I define interesting traffic, (i.e. "encrypt traffic from 1.1.1.0/24 to 2.2.2.0/24"), on the 7206 without using a crypto map?

Thanks,

Bill

[Jonn cos]

Dear Brown, my apologies but i usually get confused when not able to picture it properly. Can you kindly confirm the following

FWSM

=====

static (inside,outside) <20.0.0.1> 10.10.10.1 netmask 255.255.255.255

(ACL allowing VPN traffic between routers)

2811

===

crypto isakmp policy 10
encr 3des
hash md5
authentication pre-share
group 2

crypto isakmp key address <20.0.0.1>
crypto isakmp invalid-spi-recovery
crypto isakmp keepalive 10 3

crypto ipsec security-association replay window-size 1024
crypto ipsec transform-set TEST_SET esp-3des esp-md5-hmac

IP 20.0.0.1 is surely a fake IP but i just want to make sure that you are referring to the same IP at both places. This gives me an impression of Port redirection isnt it ? And by the way, in your 2811 you havent defined any tunnel interface so its not working properly. I am currently working on defining the config which will be out in a little time :-).

So just confirm that 2811 is hitting traffic at FWSM public IP 20.0.0.1 which you have redirected to 7206 internal IP ?

[Jonn cos]

Dear Brown,

I have completed the configuration and i am sorry about my statement of saying that interesting traffic could be defined. Ofcourse in tunnel protection we lose this feature. The workaround could be to use 2 tunnels, the first tunnel carrying encrypted traffic while the other carries non-encrypted but i dont think that would be feasible in your case. Although i have completed my configuration and everything is working fine now, and i will show the configuration here if you think its useful to you. The advantage you can have is that you have seperate tunnels to all your clients. but all of the traffic will be encrypted !!

[bbrowncisco]

Hello John,

The IP address you used is correct in my scenario.  The public IP address, which is a static NAT on the FWSM, is the same address that the 2811 is pointing to, which is indeed redirected to the 7206.  Sorry for not making that clear, and kudos for correctly identifying the situation.

Your point about the tunnel interface on the 2811 is not necessary.  In lieu of using a tunnel interface, which I cannot do for tunnels that connect to 3rd party companies, I am using instead a crypto map applied to the physical interface.

I realize now that I may have left off a crucial piece of information:  In the past when I have made changes to a crypto map ACL while the crypto map was applied to the physical interface, the result was that the physical interface became unreachable, effectively bringing down our entire network, (from an external point of view).  The only way to make changes to the ACL, for example adding another network to the list, was to first remove the crypto map from the interface, make changes to the ACL, and then reapply the crypto map.  (To save time, I had 2 versions of the map and modified the unused map ACL and then applied it afterward.)  However, even a brief downtime of all tunnels is unacceptable.  There must be a way of making modifications to one tunnel without affecting the others.

John, thanks for your replies but I'm afraid I still don't have a solution to my problem.  Am I the only one???  =)

Thanks,

Bill

[bbrowncisco]

Solution:  Use named access lists.