Colin Helliwell wrote:
OK, I've given several more hours (thrashing about wildly, in most cases)
and have got slightly further in that I am now at least getting a reply from
the server. Below are the net and ip outputs, together with the log window
from the Cisco client (in case it means anything to anyone).

Sorry for only saying this now, but it could possibly be a problem with the
client/server - I only got the software installed on the last day before we
closed for the holidays. I'll therefore try to give it a go connecting
direct to my cable modem - unfortunately this is a lengthy process since the
ISP holds the lease (with MAC address) of the firewall/router for about 4-5
hours and doesn't let another device connect! Will therefore have to wait
for a 10 hour window when my better half doesn't want to use the
PC..........Wednesday, perhaps!!
You can cut this time in half by using MAC address spoofing to set the MAC address of your firewall to that of your internal system. After the initial 4-5 hour delay, swapping PC's connected to the 'net would avoid the MAC caching delay until you resolved your problem, at which point you could disable MAC spoofing.

You could also just swap out NICs, although that could create driver issues (one advantage of standardizing on the same NIC for all systems!).

net ipfilter list
Chain input (policy DENY: 4 packets, 782 bytes):
 pkts bytes target     prot opt    tosa tosx  ifname     mark       outsize
source                destination           ports
<snip>

    5  4972 ACCEPT     udp  ------ 0xFF 0x00  *
0.0.0.0/0            0.0.0.0/0             500 ->   500
Looks like UDP 500 traffic is making it through your firewall, although I'm somewhat concerend by the non-zero deny count for the default input policy. Also, the 4 packets denied would not have been logged, so there's no telling if they were associated with your VPN trials or not.

<snip>

569    13:25:34.540  12/23/02  Sev=Info/6 DIALER/0x63300002
Initiating connection.

570    13:25:34.540  12/23/02  Sev=Info/4 CM/0x63100002
Begin connection process

571    13:25:34.590  12/23/02  Sev=Info/4 CM/0x63100004
Establish secure connection using Ethernet

572    13:25:34.590  12/23/02  Sev=Info/4 CM/0x63100026
Attempt connection with server "217.33.115.21"

573    13:25:34.590  12/23/02  Sev=Info/6 IKE/0x6300003B
Attempting to establish a connection with 217.33.115.21.

574    13:25:34.760  12/23/02  Sev=Info/4 IKE/0x63000013
SENDING >>> ISAKMP OAK AG (SA, KE, NON, ID, VID, VID, VID, VID, VID) to
217.33.115.21

575    13:25:34.760  12/23/02  Sev=Info/4 IPSEC/0x63700014
Deleted all keys

576    13:25:39.760  12/23/02  Sev=Info/4 IKE/0x63000013
SENDING >>> ISAKMP OAK AG (Retransmission) to 217.33.115.21

577    13:25:44.760  12/23/02  Sev=Info/4 IKE/0x63000013
SENDING >>> ISAKMP OAK AG (Retransmission) to 217.33.115.21

578    13:25:45.300  12/23/02  Sev=Info/5 IKE/0x6300002F
Received ISAKMP packet: peer = 217.33.115.21

579    13:25:45.300  12/23/02  Sev=Info/4 IKE/0x63000014
RECEIVING <<< ISAKMP OAK INFO (NOTIFY:NO_PROPOSAL_CHOSEN) from 217.33.115.21

580    13:25:45.300  12/23/02  Sev=Warning/3 IKE/0xA3000058
Received malformed message or negotiation no longer active (message id:
0x00000000)

581    13:25:45.300  12/23/02  Sev=Info/4 IKE/0x6300004A
Discarding IKE SA negotiation

582    13:25:45.300  12/23/02  Sev=Info/4 CM/0x63100014
Unable to establish Phase 1 SA with server "217.33.115.21" because of
"DEL_REASON_IKE_NEG_FAILED"

583    13:25:45.300  12/23/02  Sev=Info/5 CM/0x63100029
Initializing CVPNDrv

584    13:25:45.360  12/23/02  Sev=Warning/3 DIALER/0xE3300008
GI VPNStart callback failed "CM_IKE_ESTABLISH_FAIL" (3h).

585    13:25:45.410  12/23/02  Sev=Info/4 IPSEC/0x63700014
Deleted all keys
I'm not familiar with your client SW, but it looks like the first few ISAKMP packets are getting lost (or the responses are getting dropped), then a response from the server is recieved, which basically tells the client to go away (NO_PROPOSAL_CHOSEN). It looks like you need to check the settings on your client/server, authentication information, and possibly make sure there's nothing other than conventional IPSec traffic required to establish a connection. The server-side logs probably have some helpful information, as well...figuring out *WHY* the server didn't select a proposal should help narrow down where to look for trouble.

--
Charles Steinkuehler
[EMAIL PROTECTED]




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
------------------------------------------------------------------------
leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

Reply via email to