Forward Traffic for VPN Concentrator 3000 (NAT PROBLEM)

Charlie Mayes · ‎05-21-2009

Hello All,

I have been trying to forward traffic through my router to my my VPN concentrator. Please look at the config below and let know if I the correct nat confis as well as the correct ACL's. My vpn concentrator's internal ip is 10.100.1.2. All of this is being done through nat. Also I have been geting this error whenever I attempt to connect using my VPN. ( CISCO VPN - Error "Reason 412: The remote peer is no longer responding.") Please be aware that I only have one ip address for the public internet which is 74.99.240.120. Thanks.

hostname

!

boot-start-marker

boot-end-marker

!

no logging console

no logging monitor

enable

!

aaa new-model

!

aaa authentication login default local

!

aaa session-id common

clock timezone EASTERN -5

clock summer-time PCTime date Apr 6 2003 2:00 Oct 26 2003 2:00

no network-clock-participate slot 1

no network-clock-participate wic 0

ip cef

!

no ip dhcp use vrf connected

ip dhcp excluded-address 10.100.1.1 10.100.1.10

!

ip dhcp pool PRIMARYPOOL

network 10.100.1.0 255.255.255.0

domain-name

dns-server

default-router 10.100.1.1

lease 3

!

no ip domain lookup

ip domain name

ip ips notify SDEE

ip ips name sdm_ips_rule

!

crypto pki trustpoint TP-self-signed-1594146880

enrollment selfsigned

subject-name cn=IOS-Self-Signed-Certificate-1594146880

revocation-check none

rsakeypair TP-self-signed-1594146880

!

interface FastEthernet0/0

description WAN

ip address dhcp

ip access-group 110 in

ip nat outside

ip ips sdm_ips_rule in

ip virtual-reassembly

duplex auto

speed auto

!

interface Serial0/0

no ip address

shutdown

no fair-queue

!

interface FastEthernet0/1

description PRIMARYLAN$ES_LAN$

ip address 10.100.1.1 255.255.255.0

ip nat inside

ip virtual-reassembly

duplex auto

speed auto

ip http server

ip http secure-server

ip nat pool WANPOOL 74.99.240.120 74.99.240.120 netmask 255.255.255.0

ip nat inside source list 1 pool WANPOOL overload

ip nat inside source static udp 10.100.1.2 500 74.99.240.120 500 extendable

ip nat inside source static udp 10.100.1.2 4500 74.99.240.120 4500 extendable

ip nat inside source static tcp 10.100.1.2 10000 74.99.240.120 10000 extendable

ip nat inside source static udp 10.100.1.2 10000 74.99.240.120 10000 extendable

!

access-list 1 permit 10.100.1.0 0.0.0.255

access-list 101 permit tcp any 10.100.1.0 0.0.0.255 eq www established

access-list 101 permit tcp any 192.168.2.0 0.0.0.255 eq www established

access-list 102 deny tcp any host 74.99.240.120 eq telnet

access-list 102 permit ip any any

access-list 110 permit udp any host 74.99.240.120 eq isakmp

access-list 110 permit udp any host 74.99.240.120 eq non500-isakmp

access-list 110 permit udp any host 74.99.240.120 eq 62515

access-list 110 permit udp any host 74.99.240.120 eq 10000

access-list 110 permit tcp any host 74.99.240.120 eq 10000

access-list 110 permit ip any any

control-plane

Richard Burts · ‎05-21-2009

Charlie

The thing that I notice is that while you have translations for ISAKMP (UDP 500 and 4500) you do not have any translation for the ESP traffic. So the ISAKMP negotiation can occur but the IPSec traffic will not get through.

HTH

Rick

HTH

Rick

Charlie Mayes · ‎05-21-2009

I will try that and post if that works for me. Thanks.

Charlie Mayes · ‎05-21-2009

I will try that and post if that works for me. Thanks.

cisco24x7 · ‎05-21-2009

ESP will NOT work if the client is behind a NAT device. That's why you have udp-4500 for NAT-T.

Check the configuration of the Concentrator: Configuration | Tunneling and Security | IPSec | NAT Transparency.

If you check "IPSec over NAT-T" box, then you will be able to do udp-4500. This is a much preferred approach since your concentrator is behind a NAT device.

If this concentrator is doing L2L with another Cisco IOS router over the Internet, as long as you do NOT have "no crypto ipsec nat-tran udp-encap", it will do IPSec with your vpn concentrator over udp-4500 instead of ESP.

Charlie Mayes · ‎05-21-2009

Hello Rick,

I setup NAT-T on the concentrator but, I still recieve this message when I attempt to connect to the concentrator through my router.

CISCO VPN - Error "Reason 412: The remote peer is no longer responding

On my Cisco client software I have the default settings there. I have ipsec over udp and the default port 10000. Will you look at my config again on the router and see if it is missing something? I went to buy a book to resolve this issue as well the 642-511 by Cisco Press. I followed the instructions in the book and still do not understand why it is still not work and giving me that 412 error.

Richard Burts · ‎05-21-2009

Charlie

Perhaps it might help if we get some info from the client. I would suggest that you go into the client and make sure that the level for the logs on IKE, cvpnd, and IPSec are set to high. Then make an attempt to connect and post the log output for the failed attempt.

HTH

Rick

HTH

Rick

cisco24x7 · ‎05-22-2009

I have an identical setup like yours and that my VPNc sits behind a Checkpoint firewall doing NAT and that it is working fine. You must have missed something in your setup.

Post the VPNc configuration. It is a text file.

Charlie Mayes · ‎05-22-2009

How do I do that? I am new to setting up this and do not know how to get this file from the concentrator.

Charlie Mayes · ‎05-31-2009

Here are the logs from my VPN client. I think it is something wrong will my access lists on the router which will not answer for for traffic destine for udp port 500 and udp 4500 for NAT-T to work with the concentrator.

1 15:29:59.437 05/31/09 Sev=Info/6 IKE/0x6300003B

Attempting to establish a connection with 74.99.240.120.

2 15:29:59.452 05/31/09 Sev=Info/4 IKE/0x63000013

SENDING >>> ISAKMP OAK AG (SA, KE, NON, ID, VID(Xauth), VID(dpd), VID(Frag), VID(Nat-T), VID(Unity)) to 74.99.240.120

3 15:29:59.780 05/31/09 Sev=Info/4 IPSEC/0x63700008

IPSec driver successfully started

4 15:29:59.780 05/31/09 Sev=Info/4 IPSEC/0x63700014

Deleted all keys

5 15:30:04.780 05/31/09 Sev=Info/4 IKE/0x63000021

Retransmitting last packet!

6 15:30:04.780 05/31/09 Sev=Info/4 IKE/0x63000013

SENDING >>> ISAKMP OAK AG (Retransmission) to 74.99.240.120

7 15:30:09.780 05/31/09 Sev=Info/4 IKE/0x63000021

Retransmitting last packet!

8 15:30:09.780 05/31/09 Sev=Info/4 IKE/0x63000013

SENDING >>> ISAKMP OAK AG (Retransmission) to 74.99.240.120

9 15:30:14.780 05/31/09 Sev=Info/4 IKE/0x63000021

Retransmitting last packet!

10 15:30:14.780 05/31/09 Sev=Info/4 IKE/0x63000013

SENDING >>> ISAKMP OAK AG (Retransmission) to 74.99.240.120

11 15:30:19.780 05/31/09 Sev=Info/4 IKE/0x63000017

Marking IKE SA for deletion (I_Cookie=A951ED19E8D40A26 R_Cookie=0000000000000000) reason = DEL_REASON_PEER_NOT_RESPONDING

12 15:30:20.280 05/31/09 Sev=Info/4 IKE/0x6300004B

Discarding IKE SA negotiation (I_Cookie=A951ED19E8D40A26 R_Cookie=0000000000000000) reason = DEL_REASON_PEER_NOT_RESPONDING

13 15:30:20.327 05/31/09 Sev=Info/4 IKE/0x63000001

IKE received signal to terminate VPN connection

14 15:30:20.342 05/31/09 Sev=Info/4 IPSEC/0x63700014

Deleted all keys

15 15:30:20.342 05/31/09 Sev=Info/4 IPSEC/0x63700014

Deleted all keys

16 15:30:20.342 05/31/09 Sev=Info/4 IPSEC/0x63700014

Deleted all keys

17 15:30:20.342 05/31/09 Sev=Info/4 IPSEC/0x6370000A

IPSec driver successfully stopped

Richard Burts · ‎05-31-2009

Charlie

This shows that the client is attempting to contact the concentrator and is receiving no response. When you attempt to connect is there anything shown in the logs of the router? When you attempt to connect are there any hit count in the access list?

I see that the outside interface is configured with: ip ips sdm_ips_rule in. But I can find no definition of sdm_ips_rule. What is this and could it be impacting your attempt to connecct?

I wonder if you could be running into bug CSCsg64163 in which software does not handle packet fragments for port-specific NAT rules. see this link for details:

http://www.cisco.com/en/US/docs/ios/12_4t/release/notes/124TCAVS.html

HTH

Rick

HTH

Rick

Charlie Mayes · ‎05-31-2009

I tried to connect with the client then I performed a sh access lists 3 different times and it showed packets were allowed every time but I still got the 412 error.

[OK]

HQ2(config-if)#do sh access-lists

Standard IP access list 1

10 permit 10.100.1.0, wildcard bits 0.0.0.255 (32466 matches)

Extended IP access list 101

10 permit tcp any 10.100.1.0 0.0.0.255 eq www established

20 permit tcp any 192.168.2.0 0.0.0.255 eq www established

Extended IP access list 110

10 permit udp any host 74.99.240.120 eq isakmp (16 matches)

20 permit udp any host 74.99.240.120 eq non500-isakmp

30 permit udp any host 74.99.240.120 eq 62515

40 permit udp any host 74.99.240.120 eq 10000

50 permit tcp any host 74.99.240.120 eq 10000

60 permit ip any any (2286338 matches)

HQ2(config-if)#do sh access-lists

Standard IP access list 1

10 permit 10.100.1.0, wildcard bits 0.0.0.255 (32467 matches)

Extended IP access list 101

10 permit tcp any 10.100.1.0 0.0.0.255 eq www established

20 permit tcp any 192.168.2.0 0.0.0.255 eq www established

Extended IP access list 110

10 permit udp any host 74.99.240.120 eq isakmp (16 matches)

20 permit udp any host 74.99.240.120 eq non500-isakmp

30 permit udp any host 74.99.240.120 eq 62515

40 permit udp any host 74.99.240.120 eq 10000

50 permit tcp any host 74.99.240.120 eq 10000

60 permit ip any any (2286431 matches)

HQ2(config-if)#do sh access-lists

Standard IP access list 1

10 permit 10.100.1.0, wildcard bits 0.0.0.255 (32470 matches)

Extended IP access list 101

10 permit tcp any 10.100.1.0 0.0.0.255 eq www established

20 permit tcp any 192.168.2.0 0.0.0.255 eq www established

Extended IP access list 110

10 permit udp any host 74.99.240.120 eq isakmp (16 matches)

20 permit udp any host 74.99.240.120 eq non500-isakmp

30 permit udp any host 74.99.240.120 eq 62515

40 permit udp any host 74.99.240.120 eq 10000

50 permit tcp any host 74.99.240.120 eq 10000

60 permit ip any any (2286505 matches)

Richard Burts · ‎05-31-2009

Charlie

Posting the output from show access-list is pretty helpful. The point made by David is that you should be using NAT-T. But that uses UDP port 4500. And the output from your access list is that all the hits are on UDP 500. So your client is not trying to use NAT-T.

[edit] In re-reading the post I see that the number of hits in the access list each time was 16. Were you attempting access to the concentrator each time you did the show access-list? Should we expect the hit count to increment?

Can you open your client, go to the Transport tab, and tell us what options are selected there?

HTH

Rick

HTH

Rick

Charlie Mayes · ‎05-31-2009

I have (enable transparent tunneling checked and ipsec over udp (NAT/PAT).

Please look at my translations below.

HQ2#sh ip NAT Tran

Pro Inside global Inside local Outside local Outside global

udp 74.99.240.120:500 10.100.1.2:500 --- ---

udp 74.99.240.120:4500 10.100.1.2:4500 --- ---

tcp 74.99.240.120:10000 10.100.1.2:10000 --- ---

udp 74.99.240.120:10000 10.100.1.2:10000 --- ---

udp 74.99.240.120:1061 10.100.1.11:1061 192.168.1.10:161 192.168.1.10:161

tcp 74.99.240.120:1100 10.100.1.11:1100 205.234.175.175:80 205.234.175.175:80

tcp 74.99.240.120:1137 10.100.1.11:1137 64.78.157.92:443 64.78.157.92:443

tcp 74.99.240.120:1144 10.100.1.11:1144 65.54.81.209:80 65.54.81.209:80

tcp 74.99.240.120:1197 10.100.1.11:1197 157.166.224.9:80 157.166.224.9:80

tcp 74.99.240.120:1242 10.100.1.11:1242 208.111.185.10:1935 208.111.185.10:1935

tcp 74.99.240.120:1245 10.100.1.11:1245 208.111.185.10:1935 208.111.185.10:1935

tcp 74.99.240.120:1257 10.100.1.11:1257 157.166.224.9:80 157.166.224.9:80

tcp 74.99.240.120:1258 10.100.1.11:1258 66.235.142.2:80 66.235.142.2:80

tcp 74.99.240.120:1273 10.100.1.11:1273 209.34.83.28:443 209.34.83.28:443

tcp 74.99.240.120:1402 10.100.1.11:1402 76.13.15.36:23 76.13.15.36:23

tcp 74.99.240.120:1407 10.100.1.11:1407 68.142.233.94:443 68.142.233.94:443

tcp 74.99.240.120:1615 10.100.1.11:1615 207.46.107.108:1863 207.46.107.108:1863

tcp 74.99.240.120:1949 10.100.1.11:1949 207.46.124.32:1863 207.46.124.32:1863

tcp 74.99.240.120:1967 10.100.1.11:1967 4.23.40.126:80 4.23.40.126:80

Richard Burts · ‎05-31-2009

Charlie

Transparent tunneling and IPSec over UDP should be the correct choices.

I notice in looking at your post that each time you do the show access list that the hit count is 16. So it is not incrementing. Are you making an attempt to connect each time that you do show access-list? Should we expect the counter in the access list to increment?

HTH

Rick

HTH

Rick