Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > Cisco > The remote peer is no longer responding

Reply
Thread Tools

The remote peer is no longer responding

 
 
soup_or_power@yahoo.com
Guest
Posts: n/a
 
      10-22-2006
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, NOTIFYPD_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, NOTIFYPD_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 10/22/06 Sev=Info/4 IKE/0x63000013
SENDING >>> ISAKMP OAK INFO *(HASH, DEL) to 209.178.198.242

51 19:20:41.218 10/22/06 Sev=Info/4 IKE/0x6300004A
Discarding IKE SA negotiation (I_Cookie=7A8ECEC78AF9ED8C
R_Cookie=88BADF7979DF25DC) reason = DEL_REASON_PEER_NOT_RESPONDING

52 19:20:41.218 10/22/06 Sev=Info/4 CM/0x63100012
Phase 1 SA deleted before first Phase 2 SA is up cause by
"DEL_REASON_PEER_NOT_RESPONDING". 0 Crypto Active IKE SA, 0 User
Authenticated IKE SA in the system

53 19:20:41.218 10/22/06 Sev=Info/5 CM/0x63100025
Initializing CVPNDrv

54 19:20:41.218 10/22/06 Sev=Info/4 IKE/0x63000001
IKE received signal to terminate VPN connection

55 19:20:41.250 10/22/06 Sev=Info/4 IKE/0x63000085
Microsoft IPSec Policy Agent service started successfully

56 19:20:41.250 10/22/06 Sev=Info/4 IPSEC/0x63700014
Deleted all keys

57 19:20:41.250 10/22/06 Sev=Info/4 IPSEC/0x63700014
Deleted all keys

58 19:20:41.250 10/22/06 Sev=Info/4 IPSEC/0x63700014
Deleted all keys

59 19:20:41.250 10/22/06 Sev=Info/4 IPSEC/0x6370000A
IPSec driver successfully stopped

 
Reply With Quote
 
 
 
 
Walter Roberson
Guest
Posts: n/a
 
      10-23-2006
In article <(E-Mail Removed) .com>,
http://www.velocityreviews.com/forums/(E-Mail Removed) <(E-Mail Removed)> 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.
 
Reply With Quote
 
 
 
 
soup_or_power@yahoo.com
Guest
Posts: n/a
 
      10-23-2006

Walter Roberson wrote:
> In article <(E-Mail Removed) .com>,
> (E-Mail Removed) <(E-Mail Removed)> 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.255.255.255 0 0
static (inside,outside) 209.178.198.244 corp-smtp2 netmask
255.255.255.255 0 0
static (inside,outside) 209.178.198.248 sfg netmask 255.255.255.255 0 0
static (inside,outside) 209.178.198.247 pepsanchez netmask
255.255.255.255 0 0
access-group incoming in interface outside
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
timeout xlate 3:00:00
timeout conn 3:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h323
0:05:00 sip 0:30:00 sip_media 0:02:00
timeout uauth 0:05:00 absolute
aaa-server TACACS+ protocol tacacs+
aaa-server RADIUS protocol radius
http server enable
http corp-smtp2 255.255.255.255 inside
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
floodguard enable
sysopt connection permit-ipsec
sysopt ipsec pl-compatible
no sysopt route dnat
crypto ipsec transform-set iexpect esp-des esp-md5-hmac
crypto ipsec transform-set myset esp-des esp-md5-hmac
crypto dynamic-map dynmap 10 set transform-set myset
crypto map corp 1 ipsec-isakmp
crypto map corp 1 match address ipsec
crypto map corp 1 set peer 216.74.138.157
crypto map corp 1 set transform-set iexpect
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 key ******** address 216.74.138.157 netmask 255.255.255.255
isakmp identity address
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
vpngroup corphome address-pool corp-home
vpngroup corphome dns-server 192.168.1.6
vpngroup corphome wins-server 192.168.1.6
vpngroup corphome default-domain corp.iexpect.com
vpngroup corphome idle-time 1800
vpngroup corphome password ********
telnet 0.0.0.0 0.0.0.0 outside
telnet corp-smtp 255.255.255.255 inside
telnet 192.168.5.2 255.255.255.255 inside
telnet 192.168.11.0 255.255.255.0 inside
telnet 192.168.5.0 255.255.255.0 inside
telnet njrep1 255.255.255.255 inside
telnet corp-smtp2 255.255.255.255 inside
telnet timeout 5
ssh 0.0.0.0 0.0.0.0 outside
ssh 209.178.198.0 255.255.255.0 outside
ssh njrep1 255.255.255.255 inside
ssh 192.168.5.0 255.255.255.0 inside
ssh timeout 5
terminal width 80
Cryptochecksum:eca17c51a788c2eefbaebde0f2ea86f0
iexpect-corp#

 
Reply With Quote
 
Walter Roberson
Guest
Posts: n/a
 
      10-23-2006
In article <(E-Mail Removed) .com>,
(E-Mail Removed) <(E-Mail Removed)> 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)
 
Reply With Quote
 
soup_or_power@yahoo.com
Guest
Posts: n/a
 
      10-24-2006

Walter Roberson wrote:
> In article <(E-Mail Removed) .com>,
> (E-Mail Removed) <(E-Mail Removed)> 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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Reason 412: The remote peer is no longer responding. James Cisco 30 01-15-2014 08:59 AM
Remote peer no longer responding -- please help soup_or_power@yahoo.com Cisco 5 12-16-2006 11:48 PM
The remote peer is no longer responding. James Cisco 3 10-03-2006 09:40 AM
Peer no longer responding James Cisco 4 11-21-2005 03:12 PM
Need help with peer to peer no hub network Doug A Moller Wireless Networking 3 06-24-2004 01:48 AM



Advertisments