The remote peer is no longer responding [Cisco]

Prev: excessive collisions
Next: AP 1200

From: soup_or_power@yahoo.com on 22 Oct 2006 19:28

I am using VPN client to connect to a PIX firewall. I get the error:
" Secure VPN connection terminated locally by the Client. Reason 412:
The remote peer is no longer responding". I am attaching the log below.
Someone (Walter?) please
help me. Thanks & Regards

Cisco Systems VPN Client Version 4.0.5 (Rel)
Copyright (C) 1998-2003 Cisco Systems, Inc. All Rights Reserved.
Client Type(s): Windows, WinNT
Running on: 5.1.2600 Service Pack 2

1 19:19:48.890 10/22/06 Sev=Info/4 CM/0x63100002
Begin connection process

2 19:19:48.906 10/22/06 Sev=Info/4 CVPND/0xE3400001
Microsoft IPSec Policy Agent service stopped successfully

3 19:19:48.906 10/22/06 Sev=Info/4 CM/0x63100004
Establish secure connection using Ethernet

4 19:19:48.906 10/22/06 Sev=Info/4 CM/0x63100024
Attempt connection with server "209.178.198.242"

5 19:19:49.921 10/22/06 Sev=Info/6 IKE/0x6300003B
Attempting to establish a connection with 209.178.198.242.

6 19:19:49.921 10/22/06 Sev=Info/4 IKE/0x63000013
SENDING >>> ISAKMP OAK AG (SA, KE, NON, ID, VID(Xauth), VID(dpd),
VID(Nat-T), VID(Frag), VID(Unity)) to 209.178.198.242

7 19:19:49.937 10/22/06 Sev=Info/4 IPSEC/0x63700008
IPSec driver successfully started

8 19:19:49.937 10/22/06 Sev=Info/4 IPSEC/0x63700014
Deleted all keys

9 19:19:50.375 10/22/06 Sev=Info/5 IKE/0x6300002F
Received ISAKMP packet: peer = 209.178.198.242

10 19:19:50.375 10/22/06 Sev=Info/4 IKE/0x63000014
RECEIVING <<< ISAKMP OAK AG (SA, VID(Unity), VID(dpd), VID(?), KE, ID,
NON, HASH) from 209.178.198.242

11 19:19:50.375 10/22/06 Sev=Info/5 IKE/0x63000001
Peer is a Cisco-Unity compliant peer

12 19:19:50.375 10/22/06 Sev=Info/5 IKE/0x63000001
Peer supports DPD

13 19:19:50.375 10/22/06 Sev=Info/5 IKE/0x63000081
Received IOS Vendor ID with unknown capabilities flag 0x00000025

14 19:19:50.375 10/22/06 Sev=Info/6 IKE/0x63000001
IOS Vendor ID Contruction successful

15 19:19:50.375 10/22/06 Sev=Info/4 IKE/0x63000013
SENDING >>> ISAKMP OAK AG *(HASH, NOTIFY:STATUS_INITIAL_CONTACT,
VID(?), VID(Unity)) to 209.178.198.242

16 19:19:50.375 10/22/06 Sev=Info/4 IKE/0x63000082
IKE Port in use - Local Port = 0x01F4, Remote Port = 0x01F4

17 19:19:50.375 10/22/06 Sev=Info/4 CM/0x6310000E
Established Phase 1 SA. 1 Crypto Active IKE SA, 0 User Authenticated
IKE SA in the system

18 19:19:50.375 10/22/06 Sev=Info/4 CM/0x6310000E
Established Phase 1 SA. 1 Crypto Active IKE SA, 1 User Authenticated
IKE SA in the system

19 19:19:50.390 10/22/06 Sev=Info/5 IKE/0x6300005D
Client sending a firewall request to concentrator

20 19:19:50.390 10/22/06 Sev=Info/5 IKE/0x6300005C
Firewall Policy: Product=Cisco Systems Integrated Client, Capability=
(Centralized Protection Policy).

21 19:19:50.406 10/22/06 Sev=Info/4 IKE/0x63000013
SENDING >>> ISAKMP OAK TRANS *(HASH, ATTR) to 209.178.198.242

22 19:19:50.453 10/22/06 Sev=Info/5 IKE/0x6300002F
Received ISAKMP packet: peer = 209.178.198.242

23 19:19:50.453 10/22/06 Sev=Info/4 IKE/0x63000014
RECEIVING <<< ISAKMP OAK TRANS *(HASH, ATTR) from 209.178.198.242

24 19:19:50.453 10/22/06 Sev=Info/5 IKE/0x63000010
MODE_CFG_REPLY: Attribute = INTERNAL_IPV4_ADDRESS: , value =
192.168.99.1

25 19:19:50.453 10/22/06 Sev=Info/5 IKE/0x63000010
MODE_CFG_REPLY: Attribute = INTERNAL_IPV4_DNS(1): , value = 192.168.1.6

26 19:19:50.453 10/22/06 Sev=Info/5 IKE/0x63000010
MODE_CFG_REPLY: Attribute = INTERNAL_IPV4_NBNS(1) (a.k.a. WINS) : ,
value = 192.168.1.6

27 19:19:50.453 10/22/06 Sev=Info/5 IKE/0x6300000E
MODE_CFG_REPLY: Attribute = MODECFG_UNITY_DEFDOMAIN: , value =
corp.iexpect.com

28 19:19:50.453 10/22/06 Sev=Info/4 CM/0x63100019
Mode Config data received

29 19:19:50.468 10/22/06 Sev=Info/4 IKE/0x63000055
Received a key request from Driver: Local IP = 192.168.99.1, GW IP =
209.178.198.242, Remote IP = 0.0.0.0

30 19:19:50.468 10/22/06 Sev=Info/4 IKE/0x63000013
SENDING >>> ISAKMP OAK QM *(HASH, SA, NON, ID, ID) to 209.178.198.242

31 19:19:50.578 10/22/06 Sev=Info/5 IKE/0x6300002F
Received ISAKMP packet: peer = 209.178.198.242

32 19:19:50.578 10/22/06 Sev=Info/4 IKE/0x63000014
RECEIVING <<< ISAKMP OAK INFO *(HASH, NOTIFY:NO_PROPOSAL_CHOSEN) from
209.178.198.242

33 19:19:50.578 10/22/06 Sev=Warning/3 IKE/0xA300004B
Received a NOTIFY message with an invalid protocol id (0)

34 19:19:51.203 10/22/06 Sev=Info/4 IPSEC/0x63700014
Deleted all keys

35 19:19:55.703 10/22/06 Sev=Info/4 IKE/0x63000021
Retransmitting last packet!

36 19:19:55.703 10/22/06 Sev=Info/4 IKE/0x63000013
SENDING >>> ISAKMP OAK QM *(Retransmission) to 209.178.198.242

37 19:20:00.703 10/22/06 Sev=Info/4 IKE/0x63000021
Retransmitting last packet!

38 19:20:00.703 10/22/06 Sev=Info/4 IKE/0x63000013
SENDING >>> ISAKMP OAK QM *(Retransmission) to 209.178.198.242

39 19:20:05.703 10/22/06 Sev=Info/4 IKE/0x63000021
Retransmitting last packet!

40 19:20:05.703 10/22/06 Sev=Info/4 IKE/0x63000013
SENDING >>> ISAKMP OAK QM *(Retransmission) to 209.178.198.242

41 19:20:10.703 10/22/06 Sev=Info/4 IKE/0x6300002D
Phase-2 retransmission count exceeded: MsgID=041CAED1

42 19:20:10.703 10/22/06 Sev=Info/6 IKE/0x6300003D
Sending DPD request to 209.178.198.242, seq# = 1691596402

43 19:20:10.703 10/22/06 Sev=Info/4 IKE/0x63000013
SENDING >>> ISAKMP OAK INFO *(HASH, NOTIFY:DPD_REQUEST) to
209.178.198.242

44 19:20:10.703 10/22/06 Sev=Info/4 IKE/0x63000013
SENDING >>> ISAKMP OAK INFO *(HASH, DEL) to 209.178.198.242

45 19:20:10.703 10/22/06 Sev=Info/4 IKE/0x63000048
Discarding IPsec SA negotiation, MsgID=041CAED1

46 19:20:10.750 10/22/06 Sev=Info/5 IKE/0x6300002F
Received ISAKMP packet: peer = 209.178.198.242

47 19:20:10.750 10/22/06 Sev=Info/4 IKE/0x63000014
RECEIVING <<< ISAKMP OAK INFO *(HASH, NOTIFY:DPD_ACK) from
209.178.198.242

48 19:20:10.750 10/22/06 Sev=Info/5 IKE/0x6300003F
Received DPD ACK from 209.178.198.242, seq# received = 1691596403, seq#
expected = 1691596403

49 19:20:40.703 10/22/06 Sev=Info/4 IKE/0x63000017
Marking IKE SA for deletion (I_Cookie=7A8ECEC78AF9ED8C
R_Cookie=88BADF7979DF25DC) reason = DEL_REASON_PEER_NOT_RESPONDING

50 19:20:40.703

From: Walter Roberson on 23 Oct 2006 05:05

In article <1161559685.280543.199020(a)m73g2000cwd.googlegroups.com>,
soup_or_power(a)yahoo.com <soup_or_power(a)yahoo.com> wrote:
>I am using VPN client to connect to a PIX firewall. I get the error:
>" Secure VPN connection terminated locally by the Client. Reason 412:
>The remote peer is no longer responding". I am attaching the log below.
>Someone (Walter?) please
>help me. Thanks & Regards

You are getting through Phase 1 okay, but having trouble with Phase 2.

In my experience, Phase 1 is all exchanged with the public IP of the
client, but Phase 2 is exchanged with the IP that has been negotiated
for the link.

I have seen full Phase 1 with Phase 2 completely failed; in our
situation, the problem was that the routing for the negotiated IP
went by a different path than for the basic link IP -- the way we
had things arranged, it was even going to a different interface and
different vlan. It was a real puzzle in the beginning, until eventually
I happened to notice that the interface name I was seeing in the log
for the Phase 2 negotiations wasn't the expected interface.

From: soup_or_power@yahoo.com on 23 Oct 2006 11:45

Walter Roberson wrote:
> In article <1161559685.280543.199020(a)m73g2000cwd.googlegroups.com>,
> soup_or_power(a)yahoo.com <soup_or_power(a)yahoo.com> wrote:
> >I am using VPN client to connect to a PIX firewall. I get the error:
> >" Secure VPN connection terminated locally by the Client. Reason 412:
> >The remote peer is no longer responding". I am attaching the log below.
> >Someone (Walter?) please
> >help me. Thanks & Regards
>
> You are getting through Phase 1 okay, but having trouble with Phase 2.
>
> In my experience, Phase 1 is all exchanged with the public IP of the
> client, but Phase 2 is exchanged with the IP that has been negotiated
> for the link.
>
> I have seen full Phase 1 with Phase 2 completely failed; in our
> situation, the problem was that the routing for the negotiated IP
> went by a different path than for the basic link IP -- the way we
> had things arranged, it was even going to a different interface and
> different vlan. It was a real puzzle in the beginning, until eventually
> I happened to notice that the interface name I was seeing in the log
> for the Phase 2 negotiations wasn't the expected interface.

Hi Walter,
Many thanks for analyzing the logs. The IP address I used was that of
the PIX firewall. Should I be using the IP address of the host behind
the firewall? Also, I am not clear about the solution you are
suggesting. I am attaching the firewall config. Thanks & Regards

iexpect-corp# show config
: Saved
:
PIX Version 6.1(1)
nameif ethernet0 outside security0
nameif ethernet1 inside security100
enable password <>encrypted
passwd <> encrypted
hostname iexpect-corp
fixup protocol ftp 21
fixup protocol http 80
fixup protocol h323 1720
fixup protocol rsh 514
fixup protocol rtsp 554
fixup protocol sqlnet 1521
fixup protocol sip 5060
fixup protocol skinny 2000
no fixup protocol smtp 25
names
name 192.168.5.13 njrep1
name 192.168.5.150 trig1
name 192.168.5.151 trig2
name 192.168.5.61 brett
name 192.168.5.152 sfg2
name 192.168.5.9 corp-smtp2
name 192.168.5.10 corp-smtp
name 192.168.11.10 corpsmtp2
name 192.168.11.58 sfg
name 192.168.11.73 pepsanchez
access-list ipsec permit ip 192.168.5.0 255.255.255.0 10.0.255.0
255.255.255.0
access-list ipsec permit ip 192.168.11.0 255.255.255.0 10.0.255.0
255.255.255.0
access-list incoming permit tcp any host 209.178.198.243 eq smtp
access-list incoming permit tcp any host 209.178.198.244 eq smtp
access-list incoming permit icmp any any echo-reply
access-list incoming permit icmp any any time-exceeded
access-list incoming permit icmp any any unreachable
access-list incoming permit tcp any host 209.178.198.243 eq 5631
access-list incoming permit tcp any host 209.178.198.243 eq 5632
access-list incoming permit udp any host 209.178.198.243 eq 5632
access-list incoming permit udp host 216.34.112.198 eq dnsix any
access-list incoming permit udp host 216.33.202.54 eq dnsix any
access-list incoming permit tcp any eq telnet host 216.74.138.147
access-list incoming permit tcp any host 209.178.198.244 eq telnet
access-list incoming permit tcp any eq telnet host 209.178.198.244
access-list incoming permit tcp any host 209.178.198.243 eq www
access-list incoming permit tcp any host 209.178.198.244 eq www
access-list incoming permit tcp any host 209.178.198.244 eq ftp
access-list incoming permit tcp any eq ftp host 209.178.198.244
access-list incoming permit tcp any host 209.178.198.245 eq 22
access-list incoming permit tcp any host 209.178.198.245 eq www
access-list incoming permit tcp any host 209.178.198.243 eq 3389
access-list incoming permit tcp any host 209.178.198.244 eq 3389
access-list incoming permit tcp any host njrep1 eq 22
access-list incoming permit tcp any host njrep1 eq ftp
access-list incoming permit tcp any host 209.178.198.247 eq 4662
access-list incoming permit udp any host 209.178.198.247 eq 4672
access-list incoming permit tcp any host 209.178.198.249 eq www
access-list incoming permit tcp any host 209.178.198.245 eq 443
access-list incoming permit tcp any host 209.178.198.249 eq 22
access-list incoming permit tcp any host 209.178.198.254 eq 5900
access-list incoming permit tcp 202.138.142.224 255.255.255.224 host
209.178.198.248 eq 443
access-list incoming permit tcp any host 209.178.198.249 eq 443
access-list incoming permit tcp any host 209.178.198.254 eq www
access-list incoming permit tcp any host 209.178.198.254 eq 129
access-list incoming permit tcp any host 209.178.198.254 eq 132
access-list incoming permit tcp any host 209.178.198.243 eq ftp
access-list incoming permit icmp any host 209.178.198.254
access-list incoming permit icmp any host 209.178.198.243
access-list incoming permit icmp any host 209.178.198.248
access-list incoming permit tcp any host 209.178.198.243
access-list outgoing permit tcp any any
access-list outgoing permit icmp any any
access-list outgoing permit icmp any any echo-reply
access-list outgoing permit udp any any
access-list outgoing permit tcp any any eq www
access-list outgoing permit tcp any host 216.239.35.101 eq www
access-list outgoing permit udp any host 216.34.112.198 eq dnsix
access-list outgoing permit udp any host 216.33.202.54 eq dnsix
pager lines 24
logging on
interface ethernet0 10baset
interface ethernet1 10baset
mtu outside 1500
mtu inside 1500
ip address outside 209.178.198.242 255.255.255.240
ip address inside 192.168.5.1 255.255.255.0
ip audit info action alarm
ip audit attack action alarm
ip local pool corp-home 192.168.99.1-192.168.99.224
pdm history enable
arp timeout 60
global (outside) 1 209.178.198.252-209.178.198.253
global (outside) 1 209.178.198.251
nat (inside) 1 0.0.0.0 0.0.0.0 0 0
alias (inside) 192.168.5.58 209.178.198.248 255.255.255.255
alias (inside) sfg2 209.178.198.249 255.255.255.255
alias (inside) corp-smtp 209.178.198.243 255.255.255.255
alias (inside) 192.168.5.149 209.178.198.254 255.255.255.255
alias (inside) 192.168.11.150 209.178.198.245 255.255.255.255
static (inside,outside) 209.178.198.245 trig1 netmask 255.255.255.255 0
0
static (inside,outside) 209.178.198.246 trig2 netmask 255.255.255.255 0
0
static (inside,outside) 209.178.198.243 corp-smtp netmask
255.255.255.255 0 0
static (inside,outside) 209.178.198.249 sfg2 netmask 255.255.255.255 0
0
static (inside,outside) 209.178.198.254 192.168.5.149 netmask
255.255.255.255 0 0
static (inside,outside) 209.178.198.250 192.168.5.63 netmask
255

From: Walter Roberson on 23 Oct 2006 15:37

In article <1161618307.529085.103490(a)b28g2000cwb.googlegroups.com>,
soup_or_power(a)yahoo.com <soup_or_power(a)yahoo.com> wrote:

>PIX Version 6.1(1)

You really should upgrade that to get rid of the known security
problems. If you are the registered owner of the device (e.g., not
bought used via ebay) then you are entitled to a free upgrade to
the latest 6.1(*) because of the security issues.

>access-list ipsec permit ip 192.168.5.0 255.255.255.0 10.0.255.0 255.255.255.0
>access-list ipsec permit ip 192.168.11.0 255.255.255.0 10.0.255.0 255.255.255.0

>access-list outgoing permit tcp any any
>access-list outgoing permit icmp any any
>access-list outgoing permit icmp any any echo-reply

echo-reply is a subset of 'any' so the second permit icmp is redundant.

>access-list outgoing permit udp any any
>access-list outgoing permit tcp any any eq www

tcp www is a subset of the earlier tcp 'any' so the above permit is
redundant.

>access-list outgoing permit tcp any host 216.239.35.101 eq www

permit tcp to a specific hosts' www is a subset of permitting tcp
www to 'any', so this statement is redundant against the previous
(which in turn is redundant against the first)

>access-list outgoing permit udp any host 216.34.112.198 eq dnsix
>access-list outgoing permit udp any host 216.33.202.54 eq dnsix

These udp are subsets of permit udp 'any' so these are redundant.

These redundancies will not, however, have any effect on your current
difficulties.

>ip address outside 209.178.198.242 255.255.255.240
>ip address inside 192.168.5.1 255.255.255.0

>ip local pool corp-home 192.168.99.1-192.168.99.224

>global (outside) 1 209.178.198.252-209.178.198.253
>global (outside) 1 209.178.198.251

>nat (inside) 1 0.0.0.0 0.0.0.0 0 0

>alias (inside) 192.168.5.58 209.178.198.248 255.255.255.255

I was going to give you the standard warning about alias being obsolete,
but I see that you are only running 6.1(1), in which it is still
officially necessary. (Personally I never found a use for it!)

[several static, none involving 192.168.99.1]

>access-group incoming in interface outside

Your access-list 'outgoing' appears to be unused.

>route outside 0.0.0.0 0.0.0.0 209.178.198.241 1
>route inside 192.168.11.0 255.255.255.0 192.168.5.2 1
>route inside 192.168.254.0 255.255.255.0 192.168.5.2 1

>sysopt connection permit-ipsec
>sysopt ipsec pl-compatible

pl-compatible is obsolete unless you a connecting to a PIX 4 system
running an obscure add-on VPN board that uses protocols that
predate IPSec.

>crypto map corp 1 match address ipsec

>crypto map corp 10 ipsec-isakmp dynamic dynmap
>crypto map corp client configuration address initiate
>crypto map corp client configuration address respond
>crypto map corp interface outside
>isakmp enable outside

>isakmp policy 1 authentication pre-share
>isakmp policy 1 encryption des
>isakmp policy 1 hash md5
>isakmp policy 1 group 1
>isakmp policy 1 lifetime 86400
>isakmp policy 10 authentication pre-share
>isakmp policy 10 encryption des
>isakmp policy 10 hash md5
>isakmp policy 10 group 2
>isakmp policy 10 lifetime 86400

Better security policies should have lower policy numbers. des md5 group 2
is more secure than des md5 group 1, so put the group 2 entry as
a lower policy number than than the group 1 entry.

>vpngroup corphome address-pool corp-home

Okay, what you've done is configured the vpn client software to get
a link IP address from you, and that link IP is to be drawn from
the address range defined by corp-home, 192.168.99.1-192.168.99.224 .

You do not have a nat 0 access-list for traffic to 192.168.99.*
so traffic destined to that range will have its source address NAT'd
in accordance with your nat 1 / global 1 policy. So the outgoing
VPN traffic will have a source IP of 209.178.198.251, .252, or .253 .

You do not have any static or alias for the destination address
range 192.168.99.1-192.168.99.224 so the destination IP for that
traffic will not be modified by the NAT process.

At this point, you have a packet that you want to go into the
VPN tunnel, and the source IP for that packet is
209.178.198.251 - .253, and the destination IP for that packet
is 192.168.99.1-192.168.99.224 . That traffic will be compared to
the defined crypto-map match-address policies. The access-list
named 'ipsec' is not going to match that traffic because for that
access-list the destinations are 10.something .

When you connected via the VPN client software, your connection was
permitted by way of the crypto dynamic map configurations. That
connection process automatically generated a new temporary access
list with a destination equal to the negotiated address for the link,
and automatically generated a temporary match-address, and corresponding
security associations will be created.

Now what you need to know is what the *source* IP range is for that
automatically generated access-list being used in the temporary
match-address. And I think what you will find is that the source
IP for that list is *not* 209.178.198.251, .252, or .253.

To make a long story short, the fix is:

access-list nonat permit 192.168.5.0 255.255.255.0 192.168.99.0 255.255.255.255
access-list nonat permit 192.168.11.0 255.255.255.0 192.168.99.0 255.255.255.255
nat (inside) 0 access-list nonat

This will keep the PIX from NAT'ing the source IP for the traffic
destined to the VPN, so the traffic will match the automatically generated
access-list. (Test it, though -- I am not certain that the
automatically generated ACL will include 192.168.11.0 as a source)

From: soup_or_power@yahoo.com on 24 Oct 2006 09:48

Walter Roberson wrote:
> In article <1161618307.529085.103490(a)b28g2000cwb.googlegroups.com>,
> soup_or_power(a)yahoo.com <soup_or_power(a)yahoo.com> wrote:
>
> >PIX Version 6.1(1)
>
> You really should upgrade that to get rid of the known security
> problems. If you are the registered owner of the device (e.g., not
> bought used via ebay) then you are entitled to a free upgrade to
> the latest 6.1(*) because of the security issues.
>
> >access-list ipsec permit ip 192.168.5.0 255.255.255.0 10.0.255.0 255.255.255.0
> >access-list ipsec permit ip 192.168.11.0 255.255.255.0 10.0.255.0 255.255.255.0
>
> >access-list outgoing permit tcp any any
> >access-list outgoing permit icmp any any
> >access-list outgoing permit icmp any any echo-reply
>
> echo-reply is a subset of 'any' so the second permit icmp is redundant.
>
> >access-list outgoing permit udp any any
> >access-list outgoing permit tcp any any eq www
>
> tcp www is a subset of the earlier tcp 'any' so the above permit is
> redundant.
>
> >access-list outgoing permit tcp any host 216.239.35.101 eq www
>
> permit tcp to a specific hosts' www is a subset of permitting tcp
> www to 'any', so this statement is redundant against the previous
> (which in turn is redundant against the first)
>
> >access-list outgoing permit udp any host 216.34.112.198 eq dnsix
> >access-list outgoing permit udp any host 216.33.202.54 eq dnsix
>
> These udp are subsets of permit udp 'any' so these are redundant.
>
> These redundancies will not, however, have any effect on your current
> difficulties.
>
> >ip address outside 209.178.198.242 255.255.255.240
> >ip address inside 192.168.5.1 255.255.255.0
>
> >ip local pool corp-home 192.168.99.1-192.168.99.224
>
> >global (outside) 1 209.178.198.252-209.178.198.253
> >global (outside) 1 209.178.198.251
>
> >nat (inside) 1 0.0.0.0 0.0.0.0 0 0
>
> >alias (inside) 192.168.5.58 209.178.198.248 255.255.255.255
>
> I was going to give you the standard warning about alias being obsolete,
> but I see that you are only running 6.1(1), in which it is still
> officially necessary. (Personally I never found a use for it!)
>
> [several static, none involving 192.168.99.1]
>
> >access-group incoming in interface outside
>
> Your access-list 'outgoing' appears to be unused.
>
> >route outside 0.0.0.0 0.0.0.0 209.178.198.241 1
> >route inside 192.168.11.0 255.255.255.0 192.168.5.2 1
> >route inside 192.168.254.0 255.255.255.0 192.168.5.2 1
>
> >sysopt connection permit-ipsec
> >sysopt ipsec pl-compatible
>
> pl-compatible is obsolete unless you a connecting to a PIX 4 system
> running an obscure add-on VPN board that uses protocols that
> predate IPSec.
>
> >crypto map corp 1 match address ipsec
>
> >crypto map corp 10 ipsec-isakmp dynamic dynmap
> >crypto map corp client configuration address initiate
> >crypto map corp client configuration address respond
> >crypto map corp interface outside
> >isakmp enable outside
>
> >isakmp policy 1 authentication pre-share
> >isakmp policy 1 encryption des
> >isakmp policy 1 hash md5
> >isakmp policy 1 group 1
> >isakmp policy 1 lifetime 86400
> >isakmp policy 10 authentication pre-share
> >isakmp policy 10 encryption des
> >isakmp policy 10 hash md5
> >isakmp policy 10 group 2
> >isakmp policy 10 lifetime 86400
>
> Better security policies should have lower policy numbers. des md5 group 2
> is more secure than des md5 group 1, so put the group 2 entry as
> a lower policy number than than the group 1 entry.
>
> >vpngroup corphome address-pool corp-home
>
>
> Okay, what you've done is configured the vpn client software to get
> a link IP address from you, and that link IP is to be drawn from
> the address range defined by corp-home, 192.168.99.1-192.168.99.224 .
>
> You do not have a nat 0 access-list for traffic to 192.168.99.*
> so traffic destined to that range will have its source address NAT'd
> in accordance with your nat 1 / global 1 policy. So the outgoing
> VPN traffic will have a source IP of 209.178.198.251, .252, or .253 .
>
> You do not have any static or alias for the destination address
> range 192.168.99.1-192.168.99.224 so the destination IP for that
> traffic will not be modified by the NAT process.
>
> At this point, you have a packet that you want to go into the
> VPN tunnel, and the source IP for that packet is
> 209.178.198.251 - .253, and the destination IP for that packet
> is 192.168.99.1-192.168.99.224 . That traffic will be compared to
> the defined crypto-map match-address policies. The access-list
> named 'ipsec' is not going to match that traffic because for that
> access-list the destinations are 10.something .
>
> When you connected via the VPN client software, your connection was
> permitted by way of the crypto dynamic map configurations. That
> connection process automatically generated a new temporary access
> list with a destination equal to the negotiated address for the link,
> and automatically generated a temporary match-address, and corresponding
> security associations will be created.
>
> Now what you need to know is what the *source* IP range is for that
> automatically generated access-list being used in the temporary
> match-address. And I think what you will find is that the source
> IP for that list is *not* 209.178.198.251, .252, or .253.
>
>
> To make a long story short, the fix is:
>
> access-list nonat permit 192.168.5.0 255.255.255.0 192.168.99.0 255.255.255.255
> access-list nonat permit 192.168.11.0 255.255.255.0 192.168.99.0 255.255.255.255
> nat (inside) 0 access-list nonat
>
> This will keep the PIX from NAT'ing the source IP for the traffic
> destined to the VPN, so the traffic will match the automatically generated
> access-list. (Test it, though -- I am not certain that the
> automatically generated ACL will include 192.168.11.0 as a source)

Hi Walter
Many thanks for your kind response in detail. I added the above access
lists with a minor modification as follows:

access-list nonat permit ip 192.168.5.0 255.255.255.0 192.168.99.0
255.255.255.255
access-list nonat permit ip 192.168.11.0 255.255.255.0 192.168.99.0
255.255.255.255

Apparently they are not working. Kindly let me know what else to try.

Best Regards

|
Pages: 1
Prev: excessive collisions
Next: AP 1200