Basic IPSec Site-2-Site VPN configuration

[Scott Cannon]

Hi Guys,

In days past I used to configure these things on a very regular basis but I'm just trying to setup a IPsec VPN between 2 routers and I'm hitting a roadblock i dont understnad.

I have 2 routes, as I said, R1 and R2. They are directly connected to each other with an IP address of 1.0.0.1 and 1.0.0.2 resepctively. They can communicate fine.

I've creted identical P1 and P2 policies (changing peers as approrpaite) and a mirrored ACL of:

R1> permit ip host 1.0.0.1 host 1.0.0.2

R2> permit ip host 1.0.0.2 host 1.0.0.1

I've applied the crypto map to the approrpiate interface and my pings still work but my SAs dont come up. Its as though the traffic isnt interesting.

Funily enough, if i change the ACL to permit ip any any, everything works a treat. So I'm obviously not configuring the ACL preoprly. But I dont undersand what I'm missing... Any ideas?

Here's a dup of the relevant config:

R1

crypto isakmp policy 1
hash md5
authentication pre-share
group 2
lifetime 1000
crypto isakmp key pass address 1.0.0.2
!
crypto ipsec security-association lifetime seconds 1000
!
crypto ipsec transform-set default esp-des esp-md5-hmac
!
crypto map MAP1 1 ipsec-isakmp
set peer 1.0.0.2
set transform-set default
match address enc
!
!
interface FastEthernet0/0
ip address 1.0.0.1 255.255.255.252
duplex auto
speed auto
crypto map MAP1
!

ip access-list extended enc
permit ip host 1.0.0.1 host 1.0.0.2

R2

crypto isakmp policy 1
hash md5
authentication pre-share
group 2
lifetime 1000
crypto isakmp key pass address 1.0.0.1
!
crypto ipsec security-association lifetime seconds 1000
!
crypto ipsec transform-set default esp-des esp-md5-hmac
!
crypto map MAP1 1 ipsec-isakmp
set peer 1.0.0.1
set transform-set default
match address enc
!
!
interface FastEthernet0/0
ip address 1.0.0.2 255.255.255.252
duplex auto
speed auto
crypto map MAP1
!

ip access-list extended enc
permit ip host 1.0.0.2 host 1.0.0.1

TIA

Rgds

Scott

[Jennifer Halim]

You can't encrypt the tunnel end point on both sides.

I would suggest that you configure loopback interface and configure crypto ACL to match the loopback interface ip address.

Hope that helps.

[Scott Cannon]

Hi Jennifer,

Tghanks for the quick response. I'm not sure I udnersand your suggestion though. Let me expand my example to cover my real-world scenario so I can properly assess your suggestion.

R1 and R2 have a second interface each. Its actualyl the traffic from these interfaces that I want to encrypt, not actually the traffic between the tunnel endpoints. See below output for calrification:

R1(config-ext-nacl)#do sho ip int br
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            1.0.0.1         YES manual up                    up
FastEthernet0/1            2.0.0.1         YES manual up                    up

R2#sho ip int br
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            1.0.0.2         YES manual up                    up
FastEthernet0/1            3.0.0.1         YES manual up                    up

What I want is for all traffic between 2.0.0..0/24 and 3.0.0.0/24 to be encrypted. What would my ACLs have to look like to achieve this?

Thanks

Rgds

Scott

[Jennifer Halim · Accepted solution]

The ACL should be as follows:

R1: permit ip 2.0.0.0 0.0.0.255 3.0.0.0 0.0.0.255

R2: permit ip 3.0.0.0 0.0.0.255 2.0.0.0 0.0.0.255

Hope that helps.

[Scott Cannon]

Hi Jennifer,

That worked a treat. Thanks.

So, in summary, I cannot encrypt traffic point to point, I must use a loopback, right? Can you tell me why that is?

Cheers

Scott

[Jennifer Halim]

Hi Scott,

Yes, you are not supposed to encrypt the traffic end to end. However, you can encrypt one end of the tunnel towards LAN on the remote side or vice versa.

Because traffic is actually being encrypted with the end point address, hence you can't encrypt the actual peer to peer IP.

Hope that makes sense.

[Scott Cannon]

Hmmm I'm not sure...

You're suggesting that by encrypting traffic peer to peer I encrypto the IP header of the packet and as such it is unreadable by the peer in on receipt? That would make some sense, but thats wy I enabled tunnelling so that it would place an additional (albeit redundant) IP header over the encrypted traffic.. but then I spose the peer is expecting thr trafic encrypted so that wouldnt work - altough it didnt through the usual "expected encrypted packet" error.

I'll take your word for it, without a whiteboard and a good half an hour it might be a bit tough to explain in any more detail.

Thanks for all your help though, much appreciated.

Rgds

Scott