isakmpd negotiation between OpenBSD and VPCom client

[Patrick Ethier]

Hi Scott,

I am not very familiar with the the VPCom client but I could try and give
you some help. Firstly, I'm assuming you have a dynamic IP address on the
client side. I've updated my document at http://www.secureops.com/resources
that shows how to do this using RaptorMobile but the webteam hasn't put up
the new version yet (Should be done by the end of the week).

The secret here is to match up the terminology that VPCom uses with the ones
that OBSD and the RFC's use.

Things to make a note of:

1- IKE = Phase 1
2- IPsec Tunnels = Phase 2
3- Proposed times for Phase 1 have to match on both sides. OBSD sample file
has a Phase1 lifetime of 600secs or 10 minutes
4- Proposed times for Phase 2 have to match also. OBSD sample file expects
10 minutes here also.
5- Encryption algorithms and hashes need to match. Make sure same transforms
and DH groups are selected. Try specifying MODP_1024 in both the client and
OBSD
6- AGGRESSIVE mode is required on boths ends for incoming connections
dealing with variable IP addresses. This is to enable ISAKMPD to determine
which Phase 1 Configuration it should use.

Most VPN clients are very hard to debug using internal mechanisms to the
client. I use TCPDUMP on the OBSD side to see what the client is proposing.
Usually you can pick up real quick what is causing the problem in this way.

On the OBSD side of things use "tcpdump -i if0 -s1500 -v -v port 500". It'll
show you the proposals from the client to the OBSD gateway. Make sure that
what is sent is what you are expecting in your isakmpd.conf

I'm not quite sure what "Message type not supported" means but here is how
the OpenBSD side should be configured to handle a dynamic IP addressed
client.

[Phase 1]
Default=                Windows

#[Phase 2]
#Default=                Router-Windows
[Phase 2]
Passive-connections=	 ClIENT1-OBSD

#[Windows]
#Phase=                  1
#Transport=              udp
#Local-address=          172.16.1.5
#Address=                0.0.0.0
#Configuration=          Windows-main-mode
#Authentication=         secret

[Windows]
Phase=                  1
Transport=              udp
Local-address=          172.16.1.5
Configuration=          Windows-aggressive-mode

[user at Windows]
Phase=			1
Transport=			udp
Local-address=		172.16.1.5
Configuration=		Windows-aggressive-mode
Authentication=		secret
ID=				ServerID

[ServerID]
ID-type=			USER_FQDN
Name=				router at openbsd-vpn

#[Router-Windows]
#Phase=                  2
#ISAKMP-peer=            Windows
#Configuration=          Windows-quick-mode
#Local-ID=               Net-Internal
#Remote-ID=              Host-Client

#[Net-Internal]
#ID-type=                IPV4_ADDR_SUBNET
#Network=                10.10.10.0
#Netmask=                255.255.254.0

#[Host-Client]
#ID-type=                IPV4_ADDR
#Address=                10.10.10.222
#Netmask=                255.255.255.255

[CLIENT1-OBSD]
Phase=                  2
ISAKMP-peer=            user at Windows
Configuration=          Windows-quick-mode
Local-ID=               Net-Internal

[Net-Internal]
ID-type=                IPV4_ADDR_SUBNET
Network=                10.10.10.0
Netmask=                255.255.254.0

#[Windows-main-mode]
#DOI=                    IPSEC
#EXCHANGE_TYPE=          ID_PROT
#Transforms=             3DES-SHA-ANY-GROUP

[Windows-aggressive-mode]
DOI=                    IPSEC
EXCHANGE_TYPE=          AGGRESSIVE
Transforms=             3DES-SHA-ANY-GROUP

########################################

#Note that 3DES-SHA-ANY-GROUP is the same as the 3DES-SHA transform, except
#GROUP_DESCRIPTION is set to ANY.  The default of MODP_1024 did not seem to
#work.  I would simply get the message "attribute_unacceptable: got ^A,
#expected MODP_1024".

GROUP_DESCRIPTION= ANY should work fine, although specifying corresponding
DH modp's is better. I think 1536 and 1024 are valid for 3DES.

If you can(Meaning licensing issues and stuff aren't a problem), send me a
copy of the VPCom client so that I can take a good look at it. If not,
simply post the output of the TCPDUMP and we can work from there.


Good luck,
________________
Patrick Ethier
Product Development
SecureOps Inc.
patrick at secureops.com
(514) 982-0678 x 106
(514) 982-0362 - fax

VPN is sponsored by SecurityFocus.COM