VPN setup

Zindros01 · ‎11-20-2009

I am trying to setup

a site-to-site VPN

. Site A router is 79.129.63.208, site B router is 213.249.2.6. The server 10.0.0.50 to site A should exchange data with network 10.10.33.0/24 to site B.

The tunnel is not established. I get the state "MM_NO_STATE". Bellow is the configuration for site A (only importnat code). Is the deny ACL correct ? Server and network to the other end belong to different subnets. I have already tried "debug crypto isakmp sa" which returns «No peer struct to get peer description».

Any suggestions ?

!

crypto isakmp policy 1

hash md5

authentication pre-share

group 2

crypto isakmp key 3mph@s1s3ld1k0 address 213.249.2.6

!

crypto ipsec transform-set ESP-DES-MD5 esp-des esp-md5-hmac

crypto ipsec df-bit clear

!

crypto map SDM_CMAP_1 1 ipsec-isakmp

description Tunnel to 213.249.2.6

set peer 213.249.2.6

set transform-set ESP-DES-MD5

match address 104

!

interface BRI0

no ip address

encapsulation hdlc

shutdown

!

interface ATM0

no ip address

no snmp trap link-status

no atm ilmi-keepalive

pvc 8/35

encapsulation aal5mux ppp dialer

dialer pool-member 1

!

dsl operating-mode auto

!

interface FastEthernet0

!

interface FastEthernet1

!

interface FastEthernet2

!

interface FastEthernet3

!

interface Vlan1

description Connection to firewall

ip address 10.0.0.100 255.255.255.0

ip nat inside

ip virtual-reassembly

ip tcp adjust-mss 1352

no ip mroute-cache

!

interface Dialer1

mtu 1392

bandwidth 1024

ip address 79.129.63.208 255.255.255.0

ip nat outside

ip virtual-reassembly

encapsulation ppp

dialer pool 1

no cdp enable

ppp authentication chap pap callin

ppp chap hostname zaskar@otenet.gr

ppp chap password 0 p3668z1

ppp pap sent-username

zaskar@otenet.gr password 0 p3668z1

crypto map SDM_CMAP_1

!

interface Dialer0

ip address 194.219.211.144 255.255.255.0

shutdown

no cdp enable

!

ip classless

ip route 0.0.0.0 0.0.0.0 Dialer1

!

ip http server

ip http authentication local

ip http secure-server

ip http timeout-policy idle 60 life 86400 requests 10000

ip nat inside source static tcp 10.0.0.50 3389 interface Dialer1 3389

ip nat inside source static udp 10.0.0.50 1000 interface Dialer1 1000

ip nat inside source static 192.168.0.10 interface Dialer1

ip nat inside source static tcp 192.168.0.10 25 interface Dialer1 25

ip nat inside source static tcp 192.168.0.10 110 interface Dialer1 110

ip nat inside source static tcp 192.168.0.10 21 interface Dialer1 21

ip nat inside source static tcp 192.168.0.10 80 interface Dialer1 80

ip nat inside source static tcp 192.168.0.10 1723 interface Dialer1 1723

ip nat inside source static tcp 192.168.0.1 23 interface Dialer1 23

ip nat inside source static tcp 10.0.0.50 3724 interface Dialer1 3724

ip nat inside source static tcp 10.0.0.50 22001 interface Dialer1 22001

ip nat inside source route-map SDM_RMAP_1 interface Dialer1 overload

!

access-list 101 permit ip 10.0.0.0 0.0.0.255 any

access-list 104 deny ip host 10.0.0.50 10.10.33.0 0.0.0.255

access-list 104 permit ip 10.0.0.0 0.0.0.255 any

dialer-list 1 protocol ip permit

no cdp run

route-map SDM_RMAP_1 permit 1

match ip address 104

set ip next-hop 213.249.2.6

Jerry Ye · ‎11-20-2009

MM_NO_STATE realy means the main mode has failed. You should verify that the phase 1 policy is on both peers, and ensure that all the attributes match.

http://www.cisco.com/en/US/tech/tk583/tk372/technologies_tech_note09186a00800949c5.shtml#processing_main

HTH,

jerry

Zindros01 · ‎11-20-2009

jerry,

that probably means there is somewhere a parameter mismatch to complete phase 1 succesfully. I WONDER IF THIS ALSO MEANS THAT TWO PEERS PROBABLY CANNOT EXCHANGE MESSAGES AT ALL. HOW CAN WE ENSURE THAT BOTH PEERS CAN COMMUNICATE ??

Jerry Ye · ‎11-20-2009

It is possible? Have you tried to ping the remote end? Or is there any FW in between is blocking ESP? Those are the general config I will check to trouble. Also take a look at the link I've posted before. It has very detail troubleshooting steps on IPSEC VPN.

HTH,

jerry

Zindros01 · ‎11-20-2009

There is something strange. I can tracert my end BUT I cant ping it, though there is no firewall. If you take look at router config there is no "inspect" command. My ISP say they do not block any ports. Why I can't ping my peer ? Can you please look at config and check if there is any coomand that blocks pinging ?

Thanks

Jerry Ye · ‎11-20-2009

I don't see any ACL is blocking PING. Can you source it from the dialer interface to make sure

ping x.x.x.x source dial 1

Regards,

jerry

Mohamed Sobair · ‎11-21-2009

Hi,

1st: The peer seems to be not directly connected, If so, can you make sure the peer is up/running and its address routable and reachable via your ISP link.

2nd: Is this ADSL service provided by the ISP? Normally the address shouldnt be static , it should be negotiable and provided by the ISP.

Mohamed

Zindros01 · ‎11-21-2009

Dear Mohamed,

ISP says end B (213.249.2.6) is up and running. Ok, Its ADSL service and 79.129.63.208 is a static IP. I can change Dialer1 to "IP negotiated" if this does help.

I can ping end B from my office but not end A..! The strange think is that I can tracert end A from my office...! Also, from Router A I can't ping end B.

Zindros

Richard Burts · ‎11-21-2009

As others have pointed out there is a problem in the ISAKMP negotiation which is preventing the IPSec VPN from working. I agree that the first step is to verify IP reachability from the source of your ISAKMP (dialer1) to the peer address. If you verify that it is not an IP reachability issue then you should check on the parameters configured. I would suggest starting with the key and make sure that the parameters from both peers are the same.

You ask about the access list. It is not part of the problem yet, but it is not correct. In explaining the requirements you state that "The server 10.0.0.50 to site A should exchange data with network 10.10.33.0/24" but access list 104, which identifies traffic to be sent through the VPN, denies that traffic:

access-list 104 deny ip host 10.0.0.50 10.10.33.0 0.0.0.255

access-list 104 permit ip 10.0.0.0 0.0.0.255 any

and this will prevent traffic from the server going to the destination subnet from going through the VPN.

HTH

Rick

HTH

Rick

Zindros01 · ‎11-21-2009

Dear Rick,

If I ping the other end (213.249.2.6) from Router A (ping 213.249.2.6 source Dialer1) the IP is not reachable ! The problem is I can't check both ends parameters. I only have a list from ISP with required parameters for both ends. I can only login to Router A and not to both routers for cross checking. If I ping from my office the other end (213.249.2.6) is reachable but end A (79.129.63.208) its not..!

Regarding ACL, to my knowledge :

access-list 104 deny ip host 10.0.0.50 10.10.33.0 0.0.0.255 : This means the traffic from 10.0.0.50 to 10.10.33.0 is not NATed (because we don't want NAT to VPN tunnel)

access-list 104 permit ip host 10.0.0.50 any : This allows the traffic from 10.0.0.50 to "any" (we need access to Internet and to VPN tunnel)

I am wrong with above ACLs ?

Zindros

Richard Burts · ‎11-21-2009

Zindros

If you can not ping to the peer address this may suggest that there is a problem with basic IP connectivity (or it could suggest that ping is being blocked somewhere along the path). You need to find some way to confirm whether you have IP connectivity. It there is a problem with IP connectiviy then it explains the problem with IPSec and ISAKMP, since IPSec and ISAKMP can not work if there is not IP connecivity.

Access list may work fine for NAT. Bu access list 104 is also used in your crypto map to identify traffic to be processed by IPSec. And that is a problem. I suggest that you need to config a different access list to be used in the crypto map.

HTH

Rick

HTH

Rick

Zindros01 · ‎11-22-2009

Hi Rick,

regarding ACL I am not sure what change you suggest. What I have is :

access-list 101 permit ip 10.0.0.0 0.0.0.255 any
access-list 104 deny ip host 10.0.0.50 10.10.33.0 0.0.0.255
access-list 104 permit ip host 10.0.0.50 any

Is this what you suggest :

access-list 101 permit ip 10.0.0.0 0.0.0.255 any
access-list 104 deny ip host 10.0.0.50 10.10.33.0 0.0.0.255
access-list 105 permit ip host 10.0.0.50 any

Zindros

Richard Burts · ‎11-22-2009

Zindros

The main suggestion that I am making about the access list is that you should not use the same access list to control NAT and to identify traffic for IPSec VPN as you are currently doing (access list 104 is currently used both for NAT and for IPSec VPN). Create a separate access list for IPSec VPN.

It is difficult to make suggestions about the content of the access lists without knowing more about your network environment and your requirements. But what seems pretty plain from your post is that you want an access list for NAT that will deny traffic with a source address of the server and a destination address of the remote subnet and for IPSec VPN the access list should permit traffic with a source address of the server and a destination address of the remote subnet.

HTH

Rick

HTH

Rick

Zindros01 · ‎11-22-2009

Rick,

it seems strange to me also to use same ACL for "deny" and "permit". The reason I did it that way is because I found such suggestion to one of Cisco docs,

http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a0080094634.shtml

What traffic we need to have is what you described to your last mail :

1. We need a VPN tunnel from 10.0.0.50 to 10.10.33.0

2. We need Internet access from 10.0.0.50

3. We need Internet access from intrernal LAN (10.0.0.0)

Zindros

Richard Burts · ‎11-23-2009

Zindros

I have studied the link that you provide and I do not understand your post. The link explains configurations that perform both IPSec VPN and NAT. And the configurations given clearly use different access lists for IPSec crypto map and for NAT. In the configurations given in the link R2 uses access list 101 in the crypto map to identify traffic for IPSec and uses access list 175 to control NAT. The configuration for R3 is slightly more complex since it is doing both a static NAT and a dynamic NAT/PAT. The configuration for R3 uses access list 101 in the crypto map to identify traffic for IPSec, uses access list 122 to control the NAT/PAT and uses access list 150 in the route map for the static NAT.

So I do not see anything in the link that suggests using the same access list for both NAT and the crypto map for IPSec VPN.

HTH

Rick

HTH

Rick