VPN

[saquib.tandel]

Hello,

This is our EzVPN Router config, show crypto isakmp indicates Tunnel  Established but cannot ping any host behind the router to any server  behind the other end.

Server IP at other end : 192.168.1.100/24

crypto isakmp policy 10
hash md5
authentication pre-share
crypto isakmp key X.X.X.X address 1.1.1.1
crypto isakmp keepalive 300
!
!
crypto ipsec transform-set vpn esp-des esp-md5-hmac
!
crypto map vpn 10 ipsec-isakmp
set peer 1.1.1.1
set transform-set vpn
match address 111
!
!
!        
interface Ethernet0
ip address 192.168.250.1 255.255.255.0
ip nat inside
ip virtual-reassembly
ip tcp adjust-mss 1300
hold-queue 100 out
!
!
interface ATM0
bandwidth 4160
no ip address
load-interval 30
no atm ilmi-keepalive
dsl operating-mode auto
pvc 0/50
  encapsulation aal5mux ppp dialer
  dialer pool-member 1
!

!
interface Dialer0
bandwidth 4160
ip address negotiated
ip mtu 1492
ip nat outside
ip virtual-reassembly
encapsulation ppp
no ip mroute-cache
dialer pool 1
dialer-group 1
no cdp enable
ppp authentication pap callin
ppp chap refuse
ppp pap sent-username zzz password 7  AAAA
ppp ipcp address accept
crypto map vpn
!
ip route 0.0.0.0 0.0.0.0 Dialer0
ip http server
no ip http secure-server
!
ip nat inside source list 100 interface Dialer0 overload
!
access-list 100 deny   ip 192.168.250.0 0.0.0.255 192.168.2.0 0.0.0.255
access-list 100 deny   ip 192.168.250.0 0.0.0.255 192.168.1.0 0.0.0.255
access-list 100 permit ip 192.168.250.0 0.0.0.255 any

access-list 111 permit ip 192.168.250.0 0.0.0.255 192.168.1.0 0.0.0.255
access-list 111 permit ip 192.168.250.0 0.0.0.255 192.168.2.0 0.0.0.255

dialer-list 1 protocol ip permit
no cdp run

[paolo bevilacqua]

This a classic IPsec configuration, not EzVPN.

Anyway, try pinging with source LAN.

[saquib.tandel]

Hi

Tested, cannot ping with source lan.

Can you confirm if the ACL looks good ( access-list 111 permit ip 192.168.250.0 0.0.0.255 192.168.1.0 0.0.0.255 )

Are there any limitation of changing to extended ACL  ( i.e for ACL 100 and ACL 111 as per config ) ;

I try earlier extended ACL and command was not accepted  ( i.e ip nat inside source list INT interface Dialer0 overload )

Thanks

ST

[Richard Burts]

ST

It is common in configuring IPSec VPN to use extended access lists. Your access list 111 looks ok to me. And I am glad to see the configuration of address translation denies the traffic that will be permitted for VPN.

Perhaps it would help us figure out the problem is you would post the output of show crypto ipsec sa after the tunnel is established but you can not ping the remote address.

HTH

Rick

[saquib.tandel]

Hi Rick,

Thanks for replying.

When extended ping is initiated from both end then reply is ok.

IPSEC at one end is terminated on Cisco 877 and another end on Cisco PIX 515

After clearing the IPSEC tunnel ;  I notice that extended ping is must from the host behind the Cisco 877 to reach other end.

But if a host behind Pix wanna reach a host behind cisco 877  he cannot reach even with extended ping unless an extended ping is initiated from other end.

How to overcome this issue.

Thanks

ST

[Richard Burts · Accepted solution]

ST

This is a pretty simple issue and it has to do with the fact that on the router its outside IP address is dynamically learned as we can see in this part of the configuration:

interface Dialer0
ip address negotiated

In VPN configuration if both peers have static IP addresses then both peers can be configured with a peer address for the other device and either peer can do an extended ping to start the VPN tunnel. But when the router IP address is dynamically learned then the PIX can not have a peer statement with the peer address of the router. (If you check the configuration of the PIX you should find that it does not have a peer statement for the router and probably just has a peer 0.0.0.0 statement.) And if the PIX does not have a specific peer statement for the router then the PIX end can not do an extended ping to initiate the VPN tunnel. It is necessary that the VPN tunnel be started from the end that has the dynamic IP address (the router).

So I do not believe that there is anything that you can do to overcome this (except to investigate the possibility of getting a static IP address assigned for the router - which may not be very practical).

HTH

Rick

[saquib.tandel]

Hi Rick

If I understood your reply correct then it means "Traffic needs to be initiated behind the VPN Router having Dynamic IP to get the tunnel up"

Soon will have multiple subnets behind the pix so it seems for each subnet traffic needs to be initiated behind the VPN router having Dynamic IP.

Just confirm

Thanks

ST

[Richard Burts · Accepted solution]

ST

You are correct in understanding that traffic from the subnet behind the VPN router to some subnet behind the PIX will initiate the VPN tunnel.

Just to be clear - you only need traffic from behind the VPN router to the PIX once (not one for every subnet behind the PIX). Once the VPN tunnel is initialized then any subnet behind the pIX (that is properly configured for VPN access) should be able to initiate traffic to the subnet behind the VPN router.

HTH

Rick

[paolo bevilacqua]

To overcome this, just configure an IP SLA with extended pings, say every 30 seconds.