[Openswan Users] Another attempt to get connected to a SonicWALL VPN.

[Paul Wouters]

On Thu, 23 Nov 2006, Bas Driessen wrote:

> I have a Linux Desktop PC that I need to connect to a SonicWALL VPN. The
> linux PC has an ip number of 192.168.1.13 and is connected to the
> Internet via gateway 192.168.1.1. The VPN server where I need to connect
> to has an IP number of 66.nnn.nnn.nnn (for obvious security reasons I am
> using nnn here) and this connects to subnet 192.168.128.0/24. So in
> fact, I am just trying to create a VPN client to server connection.

> The details that I got from the system admin who maintains the VPN is
> that it is using the following:
>
> - SonicWALL VPN
> - ESP 3DES HMAC MD5 (IKE)
> - XAUTH authentication is not required.

Did you get a PSK as well?

> conn sonicwall
>     type=tunnel
>     auto=add
>     auth=esp
>     pfs=yes
>     authby=secret
>     keyingtries=1
>     left=192.168.1.13
>     leftsubnet=192.168.1.13/32

That's very likely wrong. Leave out leftsubnet=

>     right=66.nnn.nnn.nnn
>     rightsubnet=192.168.128.0/24
>     rightid=66.nnn.nnn.nnn
>     esp=3des-md5
>     keyexchange=ike
>     ike=3des-md5

Looks ok

> /etc/ipsec.d/sonicwall.secrets
>
> 192.168.1.13 66.nnn.nnn.nnn : PSK "somesecretkeyphrase"

and here too.

> When starting the ipsec service (/etc/rc.d/init.d/ipsec start), the
> output to screen as follows:
>
> [root at ams ipsec.d]# /sbin/service ipsec restart
> Shutting down IPsec:  Stopping Openswan IPsec...
>                                                            [  OK  ]
> Starting IPsec:  Starting Openswan IPsec 2.4.5...
> insmod /lib/modules/2.6.18-1.2849.fc6/kernel/net/key/af_key.ko
> insmod /lib/modules/2.6.18-1.2849.fc6/kernel/net/ipv4/xfrm4_tunnel.ko
                                                            [  OK  ]
Since you did auto=add, the connection is only loaded, not started.
Use auto=start to start it at startup, or run 'ipsec auto --up sonicwall'
at a later time to bring it up.

> Nov 23 14:06:36 ams pluto[16213]: | inserting event EVENT_LOG_DAILY,
> timeout in 35604 seconds

And do NOT enable plutodebug unless you are a developer or being asked to.

> When trying to create the connection, I type:
>
> /usr/sbin/ipsec whack --name sonicwall --initiate
>
> The output to screen is:
>
> [root at ams ipsec.d]# /usr/sbin/ipsec whack --name sonicwall --initiate
> 002 "sonicwall" #1: initiating Main Mode
> 104 "sonicwall" #1: STATE_MAIN_I1: initiate
> 010 "sonicwall" #1: STATE_MAIN_I1: retransmission; will wait 20s for
> response
>
> (the re-transmission errors are repeating)

Looks like the other end is rejecting on the first packet, or someone
is firewalling your packets.

> Nov 23 14:09:54 ams pluto[16661]: | *received 92 bytes from
> 66.nnn.nnn.nnn:500 on eth0 (port=500)
> Nov 23 14:09:54 ams pluto[16661]: | **parse ISAKMP Message:
> Nov 23 14:09:54 ams pluto[16661]: |    initiator cookie:
> Nov 23 14:09:54 ams pluto[16661]: |   b3 fb 6d de  b8 44 10 98
> Nov 23 14:09:54 ams pluto[16661]: |    responder cookie:
> Nov 23 14:09:54 ams pluto[16661]: |   4b c1 9a fa  48 f0 0d 6d
> Nov 23 14:09:54 ams pluto[16661]: |    next payload type: ISAKMP_NEXT_N
> Nov 23 14:09:54 ams pluto[16661]: |    ISAKMP version: ISAKMP Version

Though this seems like you received something, so I don't think these runs
are the same run.

> Nov 23 14:09:54 ams pluto[16661]: packet from 66.nnn.nnn.nnn:500:
> ignoring informational payload, type NO_PROPOSAL_CHOSEN

This is a configuration error between the two endpoints. You will have to
ask more information from the other end. You can try adding "pfs=no".

Paul