Easy VPN Server problem

[nicolas.aulagne]

I have a Cisco 881 router and try to connect a client (Cisco VPN Client 5.xxx) to this router.

Here is a schema of my network :

LAN (192.168.252.0/24)  ------ Router Cisco 881 -------- Router N°2 -------- Internet -------- Router N°3 -------- Client (192.168.1.10)

Router Cisco 881 :

- @IP lan : 192.168.252.1

- @IP wan : 192.168.0.2

- Default gateway : 192.168.0.1

- DNS : 192.168.0.1

Router N°2 :

- @IP lan : 192.168.0.1

- @IP wan : xx.xx.xx.xx

- Port forwarding : 500UDP to 192.168.0.2

- Port forwarding : 4500UDP to 192.168.0.2

I create this VPN profile :

- IP Address of Virtual Tunnel Interface : FastEthernet4

- Mode configuration : RESPOND

- Address pool (for VPN client) : 192.168.254.10 -> 192.168.254.149

- Split tunneling : 192.168.252.0/24

- Authentication : local

- No firewall (for testing only)

When I connect my VPN client for the first time, everything OK : VPN connection is Ok, and I can ping any computer on the lan (192.168.252.0/24)

If I disconnect/reconnect, the connection works, but I can't access any resources on the lan.

If I want to ping computers on the lan again, I have to :

- restart the Cisco Router

- activate/deactivate RIP (in Dynamic Routing section of CCP) : strange isn't it ?

But that will work only for one client connection : If I disconnect/reconnect the client again, then I cannot ping any resources on the lan.

I start to be crazy !

I used a sniffer Tool on a computer on my lan, and I  can see ICMP trap (ICMP request).

So ping can come from VPN to LAN, but not LAN to VPN.

Any help would be appreciated.

Thanks

Nicolas

[praprama]

Hi Nicolas,

From the debugs, phase 1 is completing but phase 2 is the one that' failing. Does not look to be issues with blocked ports or anything. This is where it's failing:

001426: Dec 10 16:16:02.769 Paris: ISAKMP: Config payload REQUEST
001427: Dec 10 16:16:02.769 Paris: ISAKMP:(2014): No provision for the request
001428: Dec 10 16:16:02.769 Paris: ISAKMP: Invalid config REQUEST

The remote router is sending some config payload request for some reason. It will be much more helpful if we have debugs frm the other router as well. Let me know when you are able to get hold of those.

In the meantime, try adding the "no-xauth" keyword at the end of the crypto isakmp key command to see if it helps:

crypto isakmp key 123456789 address xx.xx.xx.xx no-xauth

The above command has to be in place on both the routers. Let me know how it goes!

Cheers,

Prapanch

[nicolas.aulagne]

Thanks again for these suggestions

I'm gonna try to get information from the other router as soon as possible.

I will add no-xauth option in the same time

I'll keep you informed

Nicolas

[nicolas.aulagne]

Hi Prapanch,

I've had the crypto isakmp key 123456789 address xx.xx.xx.xx no-xauth on each side of the VPN.

It's still not working.

I join the log from the remote router (term mon)

I think about something : before setting the Client-to-site VPN connection, the Site-to-site VPN was working.

We can imagine that Client-to-site VPN connection configuration bring problem on the Client-to-site VPN one.

When I look a the configuration files, I noticed that on the router that support the Client-to-site VPN connection, we found :

crypto dynamic-map dyn-map 10
set transform-set ESP-3DES-SHA

!

!

crypto ipsec transform-set ESP-3DES-SHA1 esp-3des esp-sha-hmac
!

crypto map VPN_Policy 1 ipsec-isakmp
description Tunnel to yy.yy.yy.yy
set peer yy.yy.yy.yy
set transform-set ESP-3DES-SHA1
match address 100
crypto map VPN_Policy 65535 ipsec-isakmp dynamic dyn-map

On the other side, the crypto is static :

crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
!
crypto map SDM_CMAP_1 1 ipsec-isakmp
description Tunnel to xx.xx.xx.xx
set peer xx.xx.xx.xx
set transform-set ESP-3DES-SHA
match address 100

Do you think that could be a problem ? Static on one side, dynamic on he other ?

Thanks for your help

Nicolas

[praprama]

Hi Nicolas,

First off, the config looks alright to me. The dynamic-map should not affect it as the seq nunber for the dynamic map (65535) is higher than the one configured for the site to site VPN (1).

Looking at the logs, this time it's this router that is initiating the tunnel and it looks like port UDP/4500 is blocked somewhere causing the retransmission and eventual failure.

In the previous logs, it was the other router that was initiating the VPN tunnel and in that case the phase 1 came up but phase 2 failed because it receiven an invalid "config request" payload from this router.

Is there a firewall in front of the other router? Please check if port UDP/4500 is open on it. Also, please get simultameous debugs when initiating the tunnel from the other end (this end should be the responder). It should give us a better idea as to what's exactly going wrong.

Let me know how it goes!!

Thanks and Regards,

Prapanch

[nicolas.aulagne]

Hi Prapanch and thanks for your reply

There's a firewall on both side (on ISP routers).

On the site n°1, port 4500UDP was opened and forwarded on 192.168.0.2 (I send you the most recent log from this site)

On the site n°2, port 4500UDP is not open.

In fact, port 4500UDP is opened only on site n°1, because I thought this port is only needed for Client-To-Site VPN connection.

Is it necessary for Site-To-Site VPN connection too ?

So I have too forward it on the site n°2 ?

I thought port 500UDP was enough for Site-To-Site VPN connection...

Thanks in advance

Nicolas

[praprama]

Hi Nicolas,

If 4500 is not open on site 2, then we will be able to initiate the tunnel only from site 2. This explains the behavior we are seeing.

Please do get the simultaneous logs when initiatin ghte tunnel from site 2.

Cheers,

Prapanch

[nicolas.aulagne]

Just to be clear (and in order not to make any mystakes) :

On Sites 1 & 2, must be opened :

- 500 UDP port

- 4500 UDP port

Is that it ?

No other port ? TCP ?

Thanks again

Nicolas

[praprama · Accepted solution]

H Nicolas,

Yes we just need those 2 ports open.

Cheers,

Prapanch

[nicolas.aulagne]

Hi Prapanch

it finally works... thanks again

I think that adding no-xauth option help for the resolution... I also opened the 2 UDP ports on each side and the VPN just connect automatically.

Thanks again for your help (Thanks to Jennifer for the resolution of the first part of my connection problem)

Nicolas