Re: IPsec NAT VPN Issues - Page 2

andrew · ‎03-04-2007

I am having some issues with a VPN setup between an 1841 and 7206. The setup on the 1841 side is as follows;

1 x ADSL WIC

2 x F/E

Remote VPN Range 1: 10.77.0.0/21

Remote VPN Range 2: 10.116.0.0/16

Dialer0 - Public IP with /32 (NAT outside)

FE0/0 - 192.168.1.1/255.255.255.0 (NAT inside)

FE0/1 - Public IP with /28

crypto ipsec transform-set MYTRANS esp-3des esp-md5-hmac

crypto map MYMAP 10 ipsec-isakmp

set peer 203.20.x.x

set transform-set MYTRANS

match address 100

crypto map MYMAP 11 ipsec-isakmp

set peer 203.20.x.x

set transform-set MYTRANS

match address 101

int Dialer0

crypto map MYMAP

access-list 100 permit ip 192.168.1.0 0.0.0.255 10.77.0.0 0.0.0.7.255

access-list 101 permit ip 192.168.1.0 0.0.0.255 10.116.0.0 0.0.255.255

This setup is working ok apart from a few small issues. The tunnel to the VPN will only initiate properly when a ping is made from either 10.77.0.0/21 or 10.116.0.0/16 to the IP 192.168.1.1. After the VPN establishes, I can then ping the devices on the remote network. However, if I just ping anything on the 10.77.0.0 or 10.116.0.0 network, the VPN will not establish.

I have tried playing around with route-map commands and changing details of the ACLs to deny but still cannot get this working :(

Can post full config if needed

andrew · ‎03-05-2007

Good to see i'm not the only one who is scratching my head. I wouldn't call myself an expert in Cisco equipment, but I do pretty well finding my way around it all :)

Here is the config;

sh run

Building configuration...

Current configuration : 5196 bytes

!

version 12.4

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname ax-gw-01

!

boot-start-marker

boot-end-marker

!

logging buffered 52000 debugging

!

no aaa new-model

!

resource policy

!

ip cef

!

ip domain name axent.com.au

ip name-server 139.130.4.5

ip name-server 203.14.168.3

!

! crypto pki trustpoint REMOVED FOR POSTING

!

! crypto pki certificate chain REMOVED FOR POSTING

!

! username REMOVED FOR POSTING

!

crypto isakmp policy 1

encr 3des

hash md5

authentication pre-share

group 2

crypto isakmp key xxxxxxxxxxxx address 203.20.xx.xxx

!

crypto ipsec transform-set vodafone esp-3des esp-md5-hmac

!

crypto map vodafone-apn ipsec-isakmp

description Vodafone APN Network

set peer 203.20.xx.xxx

set transform-set vodafone

match address 100

!

interface FastEthernet0/0

description Axent Internal Network

ip address 192.168.1.1 255.255.255.0

ip nat inside

ip virtual-reassembly

ip tcp adjust-mss 1452

duplex auto

speed auto

!

interface FastEthernet0/1

description Axent Public Network

ip address 203.206.xxx.xxx 255.255.255.240

ip tcp adjust-mss 1452

duplex auto

speed auto

!

interface ATM0/1/0

no ip address

no atm ilmi-keepalive

dsl operating-mode ansi-dmt

!

interface ATM0/1/0.1 point-to-point

description iiNet ADSL2 Network

no snmp trap link-status

pvc 8/35

pppoe-client dial-pool-number 1

!

interface Async0/0/0

no ip address

encapsulation slip

!

interface Dialer0

ip address 203.206.xxx.xxx 255.255.255.254

ip mtu 1492

ip nat outside

ip virtual-reassembly

encapsulation ppp

dialer pool 1

dialer-group 1

ppp authentication pap callin

ppp pap sent-username adslusername password xxxxxxxx

crypto map vodafone-apn

!

ip route 0.0.0.0 0.0.0.0 Dialer0

!

ip http server

ip http access-class 2

ip http authentication local

ip http secure-server

ip http timeout-policy idle 60 life 86400 requests 10000

!

! NOTE - SOME ACLS REMOVED FOR POSTING

access-list 100 permit ip 192.168.1.0 0.0.0.255 10.77.0.0 0.0.7.255

access-list 100 permit ip 192.168.1.0 0.0.0.255 10.116.0.0 0.0.255.255

dialer-list 1 protocol ip permit

!

route-map vodafone permit 1

match ip address 100

!

control-plane

!

! banner login REMOVED FOR POSTING

!

line con 0

login local

line aux 0

line 0/0/0

stopbits 1

speed 115200

flowcontrol hardware

line vty 0 4

access-class 30 in

privilege level 15

login local

transport input telnet ssh

line vty 5 15

access-class 30 in

privilege level 15

login local

transport input telnet ssh

!

scheduler allocate 20000 1000

ntp clock-period 17178100

ntp update-calendar

ntp server 128.250.36.2 source Dialer0 prefer

end

Other things that I have also tried are;

- ACLs with deny statements as per previous posts

- Adding route-map for NAT translation

- Configured a PC at 192.168.1.2 and tried to ping from that machine. Vodafone suggested the Cisco is incapable of making the connection and that a PC on the local side would have to initiate. No avail here either.

rtanner · ‎03-05-2007

you removed the translation statement as well!

I still think you will need to stop the encypted traffic being NAT'ed first, but based on the info to hand, I cannot say why it broke everything!

I say that ( after further reading) because of the lines:

Mar 5 22:56:26.070: ISAKMP:(0): constructed NAT-T vendor-07 ID

Mar 5 22:56:26.070: ISAKMP:(0): constructed NAT-T vendor-03 ID

Mar 5 22:56:26.070: ISAKMP:(0): constructed NAT-T vendor-02 ID

and that NAT-T refers to NAT Traversal, ref RFC 3947

AS you probably noted:

from the sh crypto ipsec sa file, it looks like the 1841 is suggesting a transform of Tunnel,

(key eng. msg.) OUTBOUND local= 203.206.183.117, remote= 203.20.38.100,

local_proxy= 192.168.1.0/255.255.255.0/0/0 (type=4),

remote_proxy= 10.116.0.0/255.255.0.0/0/0 (type=4),

protocol= ESP, transform= NONE (Tunnel),

lifedur= 3600s and 4608000kb,

whereas the working one negotiates;

(key eng. msg.) INBOUND local= 203.206.183.117, remote= 203.20.38.100,

local_proxy= 192.168.1.0/255.255.255.0/0/0 (type=4),

remote_proxy= 10.116.0.0/255.255.0.0/0/0 (type=4),

protocol= ESP, transform= esp-3des esp-md5-hmac (Tunnel),

the question is why ..

and at about this time, I hope someone wlse will read this thread and say - look, there's the cause of the problem!

andrew · ‎03-06-2007

Actually, that is one thing that I hadn't noticed. After pointing that out, I made some further changes to the config by specifying an isakmp profile to match the encrytion, hash, etc. but it's still using NONE as the transform set :(

I have an 857 ADSL router that is ready to be commissioned into another branch office, so I might create a site-to-site VPN with this back to the 1841 and see whether I have the same issues. Hopefully it will point me in the right direction.

Failing everything else, is troubleshooting of this covered in the SMARTnet contract? We did order them with the routers but they are still to arrive.

rtanner · ‎03-06-2007

one more ( last?) thing - can you check the NAT table when trying to ping the PDA, and it not working? And also provide sh ip nat stat output? And, can you try the acl denying the tunnel traffic, but ensuring the NAT table is cleared ( pelase provide same output) ?

WRT SmartNet - I don't know ...

andrew · ‎03-06-2007

Okay. Some outputs for perusal :)

Router reloaded and no IPSEC connected

ax-gw-01#sh ip nat statistics

Total active translations: 0 (0 static, 0 dynamic; 0 extended)

Outside interfaces:

Virtual-Access1, Dialer0

Inside interfaces:

FastEthernet0/0

Hits: 0 Misses: 0

CEF Translated packets: 0, CEF Punted packets: 0

Expired translations: 0

Dynamic mappings:

-- Inside Source

[Id: 1] route-map vodafone interface Dialer0 refcount 0

Queued Packets: 0

ax-gw-01#

I now have a PC behind the 192.168.1.1 interface with an IP of .2

Once the tunnel is bought up from the PDA, I can ping out to 10.77/10.116 no problems. Once I bring down the tunnel, and ping from the PC, still getting stuck at PHASE_1_COMPLETE of ISAKMP.

This proves to me now that the NAT Translation is working correctly due to the reconfigured lists as follows;

ip nat inside source route-map vodafone interface Dialer0 overload

!

access-list 100 permit ip 192.168.1.0 0.0.0.255 10.77.0.0 0.0.7.255

access-list 100 permit ip 192.168.1.0 0.0.0.255 10.116.0.0 0.0.255.255

access-list 120 deny ip 192.168.1.0 0.0.0.255 10.77.0.0 0.0.7.255

access-list 120 deny ip 192.168.1.0 0.0.0.255 10.116.0.0 0.0.255.255

access-list 120 permit ip 192.168.1.0 0.0.0.255 any

!

route-map vodafone permit 1

match ip address 120

OK, now NAT Statistics. If I bring up the tunnel and ping from the PC (192.168.1.2) there are no NAT Translations in sh ip nat translations. However, they do show up when I ping a public IP address (eg. ns1.pacific.net.au)

When I ping from 192.168.1.1 I still get a zero count on the NAT statistics.

rtanner · ‎03-06-2007

clutching at straws ...

the line

crypto map vodafone-apn ipsec-isakmp

has usually a seq number in it ...

e.g.

crypto map vodafone-apn 1 ipsec-isakmp

!

http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/secur_r/srprt4/srdipsec.htm#wp1017910

states that it should not be arbitrary.

andrew · ‎03-06-2007

Unfortunately that must have been my clumsy editing whilst taking out other info because it is in the config :(

I'm going to try and setup another VPN in the meantime with the 857 that we have running at another branch. Vodafone has finally asked for a copy of the config and are also looking into it.

If anyone else is looking at these posts as well, please see if we have missed something so trivial

dradhika · ‎03-14-2007

I tried with similar configuration that you were using in my lab (with physical interfaces) and it is working correctly.

Seems the problem is not with NAT but with virtual interface (dialer) interface.

I think you need to configure crypto map both on dialer interface and the physical interface.

Check the below link for more details.

http://cco/en/US/tech/tk175/tk15/technologies_configuration_example09186a0080093e52.shtml

Config I took from your mail,

ip nat inside source route-map vodafone interface Dialer0 overload

!

access-list 100 permit ip 192.168.1.0 0.0.0.255 10.77.0.0 0.0.7.255

access-list 100 permit ip 192.168.1.0 0.0.0.255 10.116.0.0 0.0.255.255

access-list 120 deny ip 192.168.1.0 0.0.0.255 10.77.0.0 0.0.7.255

access-list 120 deny ip 192.168.1.0 0.0.0.255 10.116.0.0 0.0.255.255

access-list 120 permit ip 192.168.1.0 0.0.0.255 any

!

route-map vodafone permit 1

match ip address 120

PS:- NAT will not be applied to the traffic between 192.168.1.2 and (10.77.0.0 or 10.116.0.0) as per the above ACLs.

HTH,

Radhika

andrew · ‎03-14-2007

Hi Radhika,

I tried applying the crypto maps to both the ATM0/1/0.1 interface as well as the Dialer0 interface and still getting no further than PHASE 1 completing.

Can you shed some more light also on the NAT ACLs?

Cheers,

Andrew

dradhika · ‎03-14-2007

Attaching the information of cli configuired on both the routers. Please check if it can give you any information.

-----------

NAT router

-----------

ip nat inside source route-map vodofone interface Serial0 overload

!

route-map vodofone permit 1

match ip address natTest

!

! ip of loopback102 interface to ip of remote router's ethernet0 interface - denied - no nat done for the traffic

ip access-list extended natTest

deny ip host 10.x.x.x 18.y.y.y 0.0.0.255

permit ip host 10.x.x.x any

vpn interface :- serial0

nat outside

ip address 10.a.a.a 255.255.255.252

crypto map enabled

interface fastethernet0

nat inside

inside interface :- loopback102

ip address 10.x.x.x 255.255.255.252

! ACL used in ipsec

ip access-list extended CSM_IPSEC_ACL_1

permit ip host 10.x.x.x 18.y.y.y 0.0.0.255

! tranform set

crypto ipsec transform-set CSM_TS_1 esp-3des esp-sha-hmac

! crypto map applied on serial0 interface

crypto map CSM_CME_Serial0 1 ipsec-isakmp

description Provisioned by CSM: Peer device = 10.y.y.y

set peer 10.y.y.y

set transform-set CSM_TS_1

match address CSM_IPSEC_ACL_1

reverse-route

! preshared key

crypto isakmp key test address 10.y.y.y no-xauth

--------------

Remote Router

--------------

vpn interface :- Ethernet1

ip address 10.y.y.y 255.255.255.252

crypto map CSM_CME_Ethernet1

inside interface:- Ethernet0

ip address 18.y.y.y 255.255.255.0

! crypto map

crypto map CSM_CME_Ethernet1 1 ipsec-isakmp

description Provisioned by CSM: Peer device = 10.a.a.a

set peer 10.a.a.a

set transform-set CSM_TS_1

match address CSM_IPSEC_ACL_1

reverse-route

! tranform set

crypto ipsec transform-set CSM_TS_1 esp-3des esp-sha-hmac

! access-list used on crypto maps

ip access-list extended CSM_IPSEC_ACL_1

permit ip 18.y.y.y 0.0.0.255 host 10.x.x.x

! isakmp policy - same on both devices

crypto isakmp policy 5

encr 3des

authentication pre-share

group 5

! key

crypto isakmp key test address 10.a.a.a no-xauth

Thanks,

Radhika

pferrigan · ‎03-11-2007

I had the same type of problem, I got it working with:

crypto map s2s 1 ipsec-isakmp

description Tunnel to1.2.3.4

set peer 1.2.3.4

set transform-set s2s

match address 100

ip nat inside source list 121 pool wan overload

access-list 100 permit ip 172.16.100.0 0.0.0.255 4.3.2.0 0.0.0.255

access-list 121 deny ip 172.16.100.0 0.0.0.255 4.3.2.0 0.0.0.255

access-list 121 permit ip 172.16.100.0 0.0.0.255 any

access-list 121 permit ip 172.16.101.0 0.0.0.255 any

Where:

1.2.3.4 = vpn peer

4.3.2.0/25 = destination network

Using:

Cisco 871

The Crypto map is applied to di0, which is unnumbered to vlan1 (public ip space)

Nat is being done between di0 (out) and vlan2 (in) (172.16.100/24 network)

Hope this helps.

andrew · ‎03-13-2007

Hi Peter,

I tried replacing the NAT route-map with the IP nat source list instead, but still to no avail.

As previously mentioned, it seems strange that if I initiate the connection from the remote network(s) that the tunnel is successfully triggered but yet, when I initiate the tunnel from my end, it won't get past PHASE 1

Cisco now have an open TAC case but Vodafone won't even send them the debug logs that cisco want to see....Grrrrrr

The battle continues

andrew · ‎03-26-2007

Finally I have hit the money!

It has taken on of the Cisco TAC Engineers to coax Vodafone into providing the configuration to Cisco and we picked up straight away that Vodafone have specified PFS Group2 in the IPSEC Phase when our paperwork supplied by Vodafone indicated to use No PFS!!!!

No matter how many times they looked over the configuration they kept saying it was my issue.

I'm glad to get to the bottom of this and hope that others can read the topic and have it be of some use

Lesson Learnt: NEVER trust the paperwork and ask your provider to go through configuration details step by step

rtanner · ‎03-26-2007

thanks for letting us know the outcome!