I have a requirement to connect two internal routers over a high-speed, 3rd party, non-Internet network. The two routers need to run EIGRP with each other. We want to encrypt the link, but the routers don't support IPSec in their current configuration. Purchasing IPSec acceleration hardware for them is expensive, but we happen to have two ASAs in inventory that aren't currently in production.
The simplest solution for this is to connect the two routers with a GRE tunnel, then use the ASAs to encrypt the GRE traffic.
While I've worked with ASAs quite a bit as stateful packet filters and as remote access VPN headends, it's been a really long time since I've used one in a point-to-point VPN. I thought I'd blog about the lab proof-of-concept so that I don't forget everything about the configuration.
My lab topology looks like this:
R4---ASA1---ASA2---R5
R4 and R5 have a standard GRE tunnel configured between them, running EIGRP to advertise their loopbacks. The tunnel destination is statically routed.
On R4:
interface Loopback0
ip address 4.4.4.4 255.255.255.0
!
interface FastEthernet0/0
description link to ASA1
ip address 1.1.1.4 255.255.255.0
!
interface Tunnel50
description GRE tunnel to R5, will be encrypted by ASA1
ip address 50.1.1.4 255.255.255.0
tunnel source FastEthernet0/0
tunnel destination 2.2.2.5
!
ip route 2.2.2.5 255.255.255.255 1.1.1.1
!
router eigrp 1
network 4.0.0.0
network 50.1.1.0 0.0.0.255
On R5:
interface Loopback0
ip address 5.5.5.5 255.255.255.0
!
interface FastEthernet0/0
description link to ASA2
ip address 2.2.2.5 255.255.255.0
!
interface Tunnel50
description GRE tunnel to R4, will be encrypted by ASA2
ip address 50.1.1.5 255.255.255.0
tunnel source FastEthernet0/0
tunnel destination 1.1.1.4
!
router eigrp 1
network 5.0.0.0
network 50.1.1.0 0.0.0.255
no auto-summary
[Note: the difference in the EIGRP configs isn't a mistake. The lab routers are running two different images, one of which has auto-summary disabled by default. The other has it enabled by default, so I had to explicitly turn it off.]
This is a pretty standard GRE configuration that is used all the time to make a virtual point-to-point circuit across any other network. I'm intentionally leaving out the MTU complications for now.
Here's the interface configuration for ASA1:
interface Ethernet0/2
description link to R4
nameif inside
security-level 100
ip address 1.1.1.1 255.255.255.0
!
interface Ethernet0/1
description link to ASA2 representing 3rd party network
nameif outside
security-level 0
ip address 100.1.1.1 255.255.255.0
and here's the same configuration from ASA2:
interface Ethernet0/2
description link to R5
nameif inside
security-level 100
ip address 2.2.2.1 255.255.255.0
!
interface Ethernet0/1
description link to ASA1 representing 3rd party network
nameif outside
security-level 0
ip address 100.1.1.2 255.255.255.0
Next, we need to configure IPSec on the ASAs. This is pretty similar to doing the same thing on a IOS router, with a couple of differences:
crypto ipsec transform-set ESP_3DES esp-3des esp-sha-hmac
crypto ipsec security-association lifetime seconds 28800
crypto ipsec security-association lifetime kilobytes 4608000
crypto map P2P_CRYPTO_CM 10 match address R5_PHYSICAL
crypto map P2P_CRYPTO_CM 10 set peer 100.1.1.1
crypto map P2P_CRYPTO_CM 10 set transform-set ESP_3DES
crypto map P2P_CRYPTO_CM interface outside
crypto isakmp enable outside
crypto isakmp policy 10
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 86400
!
access-list R5_PHYSICAL extended permit ip host 2.2.2.5 host 1.1.1.4
When I first set this up, I forgot the unfamiliar crypto isakmp enable outside command, and it took me a few minutes of looking at debugs to figure out why the ASA was dropping the IKE Phase 1 packets.
The other part that's different from the IOS configuration is the presence of a "tunnel-group" that defines the tunnel type and the IKE pre-shared key:
tunnel-group 100.1.1.1 type ipsec-l2l
tunnel-group 100.1.1.1 ipsec-attributes
pre-shared-key *****
I also needed to turn off NAT control so that the ASA wouldn't drop packets without a pre-defined NAT translation:
no nat-control
The configuration on the other ASA is identical, except that the crypto ACL and peer addresses are reversed, just like they would be in an IOS configuration.
No comments:
Post a Comment