[acronce]

Oops! I meant for the above post to be a reply to the certificate based authentication thread I started here:

https://www.afp548.com/eBBS/viewtopic.php?t=181

But instead I accidentally created a new thread. Not enough coffee this morning, I guess 😉

Joel, if you want to delete this thread, please feel free.

Sorry!

Best regards,
—
Allen Cronce

[acronce]

Hi all,

I finally got it to work. It turns out that this was not specifically a Sonicwall problem. Instead it looks like might be a Racoon implementation issue.

If you remember, the problem was that the Racoon client was behaving as if it wasn’t receiving the phase 1 response from the Sonicwall. However what I found via tcpdump was that the Sonicwall was in fact sending the response. It’s just that the packet got fragmented because it was larger than the MTU (which on my Sonicwall is set to the maximum 1500 bytes).

On a hunch I tried to work around the problem by reducing the packet size and eliminate the fragmentation. By going from a 2048 to 1024 bit certificate and by removing some v3 extensions (which get incorporated into the cert as a side effect of our CA implementation), I got the Sonicwall’s response packet size below 1500 bytes.

So after making that change (and messing around with the SA definition till I got it right), I was able to connect from a Mac OS X client to the Sonicwall using certificate based authentication. Very cool!

I honestly don’t know enough about either IPSEC or the Racoon implementation to determine if this behavior with fragmented negotiation packets is a Racoon bug or not. But I posted to the Racoon mailing list in the hopes that the authors will take a look at the issue.

Best regards,
—
Allen Cronce

[acronce]

OK, so now I’ve tried to get back to basics. I pretty much started over using VaporSec to set up a shared secret based tunnel instead of certificate based. Also, I moved my TiPB out of the same range as the SonicWall and into my wireless LAN.

After fiddling with the SonicWall’s GroupVPN SA settings, the result is that I can establish the tunnel on both sides. However there are still two problems: 1) The life time expires very quickly (I think it was under a minute) and 2) Even when the tunnel is up, I’m not able to ping through to the iMac inside the SonicWall’s LAN (I see errors in the SonicWall log).

But even though the above isn’t really working, it was somewhat encouraging. So I tried hand editing VaporSec’s copy of racoon.conf in order to try to turn cert based authentication. Now I get the same error as before. Both sides time out.

So I’m still in the same boat. Any suggestions would be much appreciated.

Best regards,
—
Allen Cronce

[acronce]

Hi all,

I’m glad to hear that some of you are having success setting up a cert based VPN’s. Unfortunately I tried to do this again this weekend between a test SonicWall Tele3-TZ and my Mac OS X laptop with no success. My guess is that I have a simple routing problem (I’m much more versed in crypto than in network administration ;-). Maybe someone can help me understand what I’m doing wrong.

As far as I can tell from the logs, racoon is sending the phase 1 packet to the SonicWall, the SonicWall shows the start of the exchange in the log, but then the SonicWall is unable to send the response to phase 1 to the Mac OS X client. Both of them time out. It’s almost like a routing problem, but I’ve in my latest test, I configured the Mac with an IP address that is a peer of the test SonicWall. I can ping between the Mac and the SonicWall.

Here’s my basic set up (sorry if the layout of the text picture below gets messed up):

WAN
|
Main SonicWall
192.168.1.0 – 255
|
————————————
| |
VPN SonicWall (.5) TiPB Mac OS X (.6)
192.168.168.0 – 255
|
iMac (.2)

Note that I wanted to do my testing in my LAN, not the WAN (no spare IP addresses). So I created the above set up. The Main SonicWall is set up as a DHCP server for the clients, so both the VPN SonicWall and the PowerBook are in the local reserved IP range of 192.168.1.0. I’ve configured the VPN SonicWall to be a DHCP server for a different reserved IP range (192.168.168.0). The iMac is assigned an IP from this range.

I’ve configured my setkey input file as follows:

flush;
spdflush;
spdadd 192.168.168.0/24 192.168.1.106/32 any -P in ipsec esp/tunnel/192.168.1.105-192.168.1.106/require;
spdadd 192.168.1.106/32 192.168.168.0/24 any -P out ipsec esp/tunnel/192.168.1.106-192.168.1.105/require;

======================================

Here’s my racoon.conf:

# $KAME: racoon.conf.in,v 1.17 2001/08/14 12:10:22 sakane Exp $

# “path” must be placed before it should be used.
# You can overwrite which you defined, but it should not use due to confusing.
path include “/etc/racoon” ;
#include “remote.conf” ;

# search this file for pre_shared_key with various ID key.
path pre_shared_key “/etc/racoon/psk.txt” ;

# racoon will look for certificate file in the directory,
# if the certificate/certificate request payload is received.
path certificate “/etc/racoon/cert” ;

# “log” specifies logging level. It is followed by either “notify”, “debug”
# or “debug2”.
log debug;

# “padding” defines some parameter of padding. You should not touch these.
padding
{
maximum_length 20; # maximum padding length.
randomize off; # enable randomize length.
strict_check off; # enable strict check.
exclusive_tail off; # extract last one octet.
}

# if no listen directive is specified, racoon will listen to all
# available interface addresses.
listen
{
#isakmp ::1 [7000];
#isakmp 202.249.11.124 [500];
#admin [7002]; # administrative’s port by kmpstat.
#strict_address; # required all addresses must be bound.
}

# Specification of default various timer.
timer
{
# These value can be changed per remote node.
counter 5; # maximum trying count to send.
interval 20 sec; # maximum interval to resend.
persend 1; # the number of packets per a send.

# timer for waiting to complete each phase.
phase1 30 sec;
phase2 15 sec;
}

remote anonymous
{
exchange_mode aggressive;
doi ipsec_doi;
situation identity_only;

my_identifier asn1dn;
peers_identifier asn1dn;
verify_identifier on;
certificate_type x509 “newcert.pem” “privkey.pem”;

nonce_size 16;
lifetime time 1 min; # sec,min,hour
initial_contact on;
support_mip6 on;
proposal_check obey; # obey, strict or claim

proposal {
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method rsasig ;
dh_group 2 ;
}
}

remote ::1 [8000]
{
exchange_mode aggressive;
doi ipsec_doi;
situation identity_only;

my_identifier asn1dn;
peers_identifier asn1dn;
certificate_type x509 “newcert.pem” “privkey.pem”;

nonce_size 16;
lifetime time 1 min; # sec,min,hour

proposal {
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method rsasig ;
dh_group 2 ;
}
}

sainfo anonymous
{
pfs_group 1;
lifetime time 30 sec;
encryption_algorithm 3des ;
authentication_algorithm hmac_sha1;
compression_algorithm deflate ;
}

# sainfo address 203.178.141.209 any address 203.178.141.218 any
# {
# pfs_group 1;
# lifetime time 30 sec;
# encryption_algorithm des ;
# authentication_algorithm hmac_md5;
# compression_algorithm deflate ;
# }

sainfo address ::1 icmp6 address ::1 icmp6
{
pfs_group 1;
lifetime time 60 sec;
encryption_algorithm 3des, cast128, blowfish 448, des ;
authentication_algorithm hmac_sha1, hmac_md5 ;
compression_algorithm deflate ;
}

======================================
On the SonicWall side, I have the following configuration for the SA:

IPSec Keyring Mode: IKE using 3rd Party Certificates
Select certificate: << a cert issued to the SonicWall from our CA>>
IPSec Gateway Name or Address: 0.0.0.0

Exchange: Aggressive Mode
Phase 1 DH Group: Group 2
SA Life time: 28800
Phase 1 Encrypt/Auth: 3DES & SHA1
Phase 2 Encrypt/Auth: Strong Encrypt and Authenticate (ESP 3DES HMAC SHA1)

ID Type: Distinguished Name

/C=US/ST=CA/L=San Jose/, etc, etc, etc.

Destination Networks: Specify destination networks below:
192.168.1.0 255.255.255.0

======================================

When I ping the iMac (192.168.168.2) from the TiPB (192.168.1.106), racoon tries to do it’s thing. But it times out waiting for the phase 1 response from the SonicWall. Here are the racoon.log entries (note that I’ve omitted the certificate, key and packet dump data from the log):

2003-03-30 22:56:47: DEBUG: grabmyaddr.c:494:autoconf_myaddrsport(): 5 addrs are configured successfully
2003-03-30 22:56:47: INFO: isakmp.c:1357:isakmp_open(): 192.168.1.106[500] used as isakmp port (fd=5)
2003-03-30 22:56:47: INFO: isakmp.c:1357:isakmp_open(): fe80::230:65ff:fef8:915e[500] used as isakmp port (fd=6)
2003-03-30 22:56:47: INFO: isakmp.c:1357:isakmp_open(): 127.0.0.1[500] used as isakmp port (fd=7)
2003-03-30 22:56:47: INFO: isakmp.c:1357:isakmp_open(): fe80::1[500] used as isakmp port (fd=8)
2003-03-30 22:56:47: INFO: isakmp.c:1357:isakmp_open(): ::1[500] used as isakmp port (fd=9)
2003-03-30 22:56:47: DEBUG: pfkey.c:192:pfkey_handler(): get pfkey X_SPDDUMP message
2003-03-30 22:56:47: DEBUG: pfkey.c:192:pfkey_handler(): get pfkey X_SPDDUMP message
2003-03-30 22:56:47: DEBUG: policy.c:184:cmpspidxstrict(): sub:0xbffff9e0: 192.168.1.106/32[0] 192.168.168.0/24[0] proto=any dir=out
2003-03-30 22:56:47: DEBUG: policy.c:185:cmpspidxstrict(): db :0xac1c8: 192.168.168.0/24[0] 192.168.1.106/32[0] proto=any dir=in
2003-03-30 22:58:17: DEBUG: pfkey.c:192:pfkey_handler(): get pfkey ACQUIRE message
2003-03-30 22:58:17: DEBUG: pfkey.c:1519:pk_recvacquire(): suitable outbound SP found: 192.168.1.106/32[0] 192.168.168.0/24[0] proto=any dir=out.
2003-03-30 22:58:17: DEBUG: policy.c:184:cmpspidxstrict(): sub:0xbffff9d0: 192.168.168.0/24[0] 192.168.1.106/32[0] proto=any dir=in
2003-03-30 22:58:17: DEBUG: policy.c:185:cmpspidxstrict(): db :0xac1c8: 192.168.168.0/24[0] 192.168.1.106/32[0] proto=any dir=in
2003-03-30 22:58:17: DEBUG: pfkey.c:1535:pk_recvacquire(): suitable inbound SP found: 192.168.168.0/24[0] 192.168.1.106/32[0] proto=any dir=in.
2003-03-30 22:58:17: DEBUG: pfkey.c:1574:pk_recvacquire(): new acquire 192.168.1.106/32[0] 192.168.168.0/24[0] proto=any dir=out
2003-03-30 22:58:17: DEBUG: sainfo.c:100:getsainfo(): anonymous sainfo selected.
2003-03-30 22:58:17: DEBUG: proposal.c:825:printsaproto(): (proto_id=ESP spisize=4 spi=00000000 spi_p=00000000 encmode=Tunnel reqid=0:0)
2003-03-30 22:58:17: DEBUG: proposal.c:859:printsatrns(): (trns_id=3DES encklen=0 authtype=2)
2003-03-30 22:58:17: DEBUG: remoteconf.c:129:getrmconf(): anonymous configuration selected for 192.168.1.105.
2003-03-30 22:58:17: INFO: isakmp.c:1681:isakmp_post_acquire(): IPsec-SA request for 192.168.1.105 queued due to no phase1 found.
2003-03-30 22:58:17: DEBUG: isakmp.c:790:isakmp_ph1begin_i(): ===
2003-03-30 22:58:17: INFO: isakmp.c:795:isakmp_ph1begin_i(): initiate new phase 1 negotiation: 192.168.1.106[500]<=>192.168.1.105[500]
2003-03-30 22:58:17: INFO: isakmp.c:800:isakmp_ph1begin_i(): begin Aggressive mode.
2003-03-30 22:58:17: DEBUG: isakmp.c:1993:isakmp_newcookie(): new cookie:
Blah blah blah
2003-03-30 22:58:17: DEBUG: localconf.c:253:getpathname(): filename: /etc/racoon/cert/newcert.pem
2003-03-30 22:58:17: DEBUG: oakley.c:1458:get_cert_fromlocal(): Certificate:
Data:
Blah blah blah
2003-03-30 22:58:17: DEBUG: oakley.c:1497:get_cert_fromlocal(): created CERT payload:
2003-03-30 22:58:17: DEBUG: plog.c:193:plogdump():
Blah blah blah
2003-03-30 22:58:17: DEBUG: ipsec_doi.c:3187:ipsecdoi_setid1(): use ID type of DER_ASN1_DN
2003-03-30 22:58:17: DEBUG: oakley.c:253:oakley_dh_generate(): compute DH’s private.
2003-03-30 22:58:17: DEBUG: plog.c:193:plogdump():
Blah blah blah
2003-03-30 22:58:17: DEBUG: oakley.c:255:oakley_dh_generate(): compute DH’s public.
2003-03-30 22:58:17: DEBUG: plog.c:193:plogdump():
Blah blah blah
2003-03-30 22:58:17: DEBUG: oakley.c:1960:oakley_getcr(): create my CR: X.509 Certificate Signature
2003-03-30 22:58:17: DEBUG: isakmp_agg.c:162:agg_i1send(): authmethod is RSA signatures
2003-03-30 22:58:17: DEBUG: isakmp.c:2110:set_isakmp_payload(): add payload of len 48, next type 4
2003-03-30 22:58:17: DEBUG: isakmp.c:2110:set_isakmp_payload(): add payload of len 128, next type 10
2003-03-30 22:58:17: DEBUG: isakmp.c:2110:set_isakmp_payload(): add payload of len 16, next type 5
2003-03-30 22:58:17: DEBUG: isakmp.c:2110:set_isakmp_payload(): add payload of len 278, next type 7
2003-03-30 22:58:17: DEBUG: isakmp.c:2110:set_isakmp_payload(): add payload of len 1, next type 0
2003-03-30 22:58:17: DEBUG: sockmisc.c:421:sendfromto(): sockname 192.168.1.106[500]
2003-03-30 22:58:17: DEBUG: sockmisc.c:423:sendfromto(): send packet from 192.168.1.106[500]
2003-03-30 22:58:17: DEBUG: sockmisc.c:425:sendfromto(): send packet to 192.168.1.105[500]
2003-03-30 22:58:17: DEBUG: sockmisc.c:563:sendfromto(): 1 times of 519 bytes message will be sent to 192.168.1.106[500]
2003-03-30 22:58:17: DEBUG: plog.c:193:plogdump():
Blah blah blah
2003-03-30 22:58:17: DEBUG: isakmp.c:1446:isakmp_ph1resend(): resend phase1 packet 1c29e783cdb1e6bb:0000000000000000
2003-03-30 22:58:29: DEBUG: pfkey.c:192:pfkey_handler(): get pfkey ACQUIRE message
2003-03-30 22:58:29: DEBUG: pfkey.c:1503:pk_recvacquire(): ignore the acquire becuase ph2 found
2003-03-30 22:58:37: DEBUG: sockmisc.c:421:sendfromto(): sockname 192.168.1.106[500]
2003-03-30 22:58:37: DEBUG: sockmisc.c:423:sendfromto(): send packet from 192.168.1.106[500]
2003-03-30 22:58:37: DEBUG: sockmisc.c:425:sendfromto(): send packet to 192.168.1.105[500]
2003-03-30 22:58:37: DEBUG: sockmisc.c:563:sendfromto(): 1 times of 519 bytes message will be sent to 192.168.1.106[500]
2003-03-30 22:58:37: DEBUG: plog.c:193:plogdump():
Blah blah blah
2003-03-30 22:58:37: DEBUG: isakmp.c:1446:isakmp_ph1resend(): resend phase1 packet 1c29e783cdb1e6bb:0000000000000000
2003-03-30 22:58:38: DEBUG: pfkey.c:192:pfkey_handler(): get pfkey ACQUIRE message
2003-03-30 22:58:38: DEBUG: pfkey.c:1503:pk_recvacquire(): ignore the acquire becuase ph2 found
2003-03-30 22:58:48: ERROR: isakmp.c:1773:isakmp_chkph1there(): phase2 negotiation failed due to time up waiting for phase1. ESP 192.168.1.105->192.168.1.106
2003-03-30 22:58:48: INFO: isakmp.c:1778:isakmp_chkph1there(): delete phase 2 handler.

======================================

And here’s the corresponding log from the SonicWall:

SonicWALL 0040-1015-2265 Log (part 1) dumped to email at 03/31/2003 08:12:42.512
03/31/2003 07:57:56.032 – Log Cleared
03/31/2003 08:09:46.016 – IKE Responder: Received Aggressive Mode request (Phase 1) – Source:192.168.1.106 – Destination:192.168.1.105 – –
03/31/2003 08:09:46.304 – NAT Discovery : Peer IPSec Security Gateway doesn’t support VPN NAT Traversal – Source:192.168.1.105 – Destination:192.168.1.106 – –
03/31/2003 08:09:54.608 – IKE Responder: No response – remote party timeout – Source:192.168.1.105, 500 – Destination:192.168.1.106, 500 – –
03/31/2003 08:10:03.608 – IKE Responder: No response – remote party timeout – Source:192.168.1.105, 500 – Destination:192.168.1.106, 500 – –
03/31/2003 08:10:06.496 – Received packet retransmission. Drop duplicate packet – Source:192.168.1.106 – Destination:192.168.1.105 – –
03/31/2003 08:10:19.624 – IKE Responder: No response – remote party timeout – Source:192.168.1.105, 500 – Destination:192.168.1.106, 500 – –
03/31/2003 08:10:26.496 – Received packet retransmission. Drop duplicate packet – Source:192.168.1.106 – Destination:192.168.1.105 – –
03/31/2003 08:10:46.496 – Received packet retransmission. Drop duplicate packet – Source:192.168.1.106 – Destination:192.168.1.105 – –
03/31/2003 08:10:52.624 – IKE SA lifetime expired. – Source:192.168.1.105 – Destination:192.168.1.106 – –
03/31/2003 08:11:06.512 – IKE Responder: Received Aggressive Mode request (Phase 1) – Source:192.168.1.106 – Destination:192.168.1.105 – –
03/31/2003 08:11:06.800 – NAT Discovery : Peer IPSec Security Gateway doesn’t support VPN NAT Traversal – Source:192.168.1.105 – Destination:192.168.1.106 – –
03/31/2003 08:11:15.608 – IKE Responder: No response – remote party timeout – Source:192.168.1.105, 500 – Destination:192.168.1.106, 500 – –
03/31/2003 08:11:23.608 – IKE Responder: No response – remote party timeout – Source:192.168.1.105, 500 – Destination:192.168.1.106, 500 – –
03/31/2003 08:11:26.512 – Received packet retransmission. Drop duplicate packet – Source:192.168.1.106 – Destination:192.168.1.105 – –
03/31/2003 08:11:40.624 – IKE Responder: No response – remote party timeout – Source:192.168.1.105, 500 – Destination:192.168.1.106, 500 – –
03/31/2003 08:12:15.608 – IKE negotiation aborted due to timeout – Source:192.168.1.105 – Destination:192.168.1.106 – –

======================================

I think that’s just about all of the relevant info. If anyone has any clues as to what the problem is, please let me know.

Thanks in advance!

Best regards,
—
Allen Cronce

[Author]

Posts