[strongSwan] can't connect to SonicWall VPN with strongSwan

Dave Schmidt someguyfromiowa at gmail.com
Tue Feb 13 17:09:47 CET 2018


I tried enabling the unity option as shown below but I still get the same
log output.

/etc/strongswan.d/charon.conf:    # Send Cisco Unity vendor ID payload
(IKEv1 only).
/etc/strongswan.d/charon.conf:    cisco_unity = yes
/etc/strongswan.d/charon/unity.conf:unity {
/etc/strongswan.d/charon/unity.conf-    load = yes

Here is what I see in my terminal after 'sudo ipsec up test3' :

initiating Aggressive Mode IKE_SA test3[1] to xxx.yyy.xxx.yyy
generating AGGRESSIVE request 0 [ SA KE No ID V V V V V ]
sending packet: from 192.168.1.34[500] to xxx.yyy.xxx.yyy[500] (396 bytes)
received packet: from xxx.yyy.xxx.yyy[500] to 192.168.1.34[500] (408 bytes)
parsed AGGRESSIVE response 0 [ SA KE No ID V V V NAT-D NAT-D V V HASH ]
received unknown vendor ID: 40:4b:f4:39:52:2c:a3:f6
received unknown vendor ID: 5b:36:2b:c8:20:f6:00:07
received NAT-T (RFC 3947) vendor ID
received DPD vendor ID
received XAuth vendor ID
local host is behind NAT, sending keep alives
generating AGGRESSIVE request 0 [ HASH NAT-D NAT-D ]
sending packet: from 192.168.1.34[4500] to xxx.yyy.xxx.yyy[4500] (108 bytes)
received packet: from xxx.yyy.xxx.yyy[4500] to 192.168.1.34[4500] (76 bytes)
parsed TRANSACTION request 375526604 [ HASH CPRQ(X_TYPE X_USER X_PWD) ]
generating TRANSACTION response 375526604 [ HASH CPRP(X_USER X_PWD) ]
sending packet: from 192.168.1.34[4500] to xxx.yyy.xxx.yyy[4500] (92 bytes)
received packet: from xxx.yyy.xxx.yyy[4500] to 192.168.1.34[4500] (92 bytes)
queueing INFORMATIONAL_V1 request as tasks still active
received packet: from xxx.yyy.xxx.yyy[4500] to 192.168.1.34[4500] (76 bytes)
parsed TRANSACTION request 1995451065 [ HASH CPS(X_STATUS) ]
XAuth authentication of 'dschmidt' (myself) successful
IKE_SA test3[1] established between 192.168.1.34[192.168.1.34]...
xxx.yyy.xxx.yyy[0017C56721AC]
scheduling reauthentication in 27800s
maximum IKE_SA lifetime 28340s
generating TRANSACTION response 1995451065 [ HASH CPA(X_STATUS) ]
sending packet: from 192.168.1.34[4500] to xxx.yyy.xxx.yyy[4500] (76 bytes)
parsed INFORMATIONAL_V1 request 3572062565 [ HASH N(INITIAL_CONTACT) ]
generating TRANSACTION request 3329385279 [ HASH CPRQ(ADDR DNS) ]
sending packet: from 192.168.1.34[4500] to xxx.yyy.xxx.yyy[4500] (76 bytes)
received packet: from xxx.yyy.xxx.yyy[4500] to 192.168.1.34[4500] (92 bytes)
parsed INFORMATIONAL_V1 request 184943178 [ HASH D ]
received DELETE for IKE_SA test3[1]
deleting IKE_SA test3[1] between 192.168.1.34[192.168.1.34]...
xxx.yyy.xxx.yyy[0017C56721AC]
initiating Aggressive Mode IKE_SA test3[2] to xxx.yyy.xxx.yyy
generating AGGRESSIVE request 0 [ SA KE No ID V V V V V ]
sending packet: from 192.168.1.34[500] to xxx.yyy.xxx.yyy[500] (396 bytes)
establishing connection 'test3' failed

Thanks,
Dave

On Tue, Feb 13, 2018 at 7:33 AM, Dave Schmidt <someguyfromiowa at gmail.com>
wrote:

> Thanks Justin. I tried changing modecfg to pull and already had
> leftsourceip=%config. The connection still failed similarly but this time
> there was no attempt to assign an IP to the responder.
>
>

> These are the parameters from the Global VPN client in Windows that will
> successfully connect:
> negotiated phase I parameters:
> 3DES-CBC (192 bits)
> MD5
> XAuth with PSK
> DH Group 2
>
> negotiated phase II parameters:
> ESP
> UDP encapsulation tunnel
> AES (256 bits)
> HMAC-SHA
> DH Group 2
>
> Destination proxy IDs:
> network                       subnet mask          port          state
> 10.1.11.0                     255.255.255.0        BOOTPS  complete
> 10.1.11.0                     255.255.255.0        any           idle
> 10.1.24.0                     255.255.248.0        any
> idle
> <remote external IP>    255.255.255.255    any           idle
>
> Packet sending:
> response timeout  3 sec
> maximum attempts 3
> dead peer detection automatic
> check for dead peer every 5 sec
> assume peer is dead after 5 failed checks
>
> Networking:
> NAT traversal: automatic
>
> Global VPN client usually assigns me this virtual IP: 10.1.11.63
>
> I also know that the internal IP of the sonicWall is 10.1.30.1.
>
> Here is my ipsec.conf file:
> conn %default
>     keyexchange=ikev1
>     #added by DS
>     keyingtries=5
>     ike=aes256-sha1-modp1024
>     esp=aes256-sha1-modp1024
>
>     #added by DS
>     ikelifetime=28800s
>     lifetime=28800s
>     dpdaction=restart
>     dpdtimeout=150s
>     dpddelay=5s
>
>     #from roadwarrior config example
>     fragmentation=yes
>
> conn    test3
>     aggressive=yes
>     authby=psk
>     leftauth=psk
>     rightauth=psk
>     leftauth2=xauth
>     xauth_identity=dschmidt
>     #modeconfig=push
>     modeconfig=pull
>
>     right=<external IP of sonicwall>
>     rightauth=psk
>     #rightsourceip=%config
>     #rightsourceip=10.1.11.0/16
>     #rightsourceip=10.1.30.1
>     rightsubnet=0.0.0.0/0
>     rightid=%any
>
>     leftfirewall=yes
>     #virtual IP page says leftsubnet defaults to %dynamic and must not be
> set if virtual IP is desired
>     #leftsubnet=10.1.11.0/16
>     leftid=192.168.1.34
>     #documentation says required for arbitrary virtual IP for client from
> responder
>     leftsourceip=%config
>     auto=add
>
> Thanks again,
> Dave
>
> On Mon, Feb 12, 2018 at 11:48 PM, Justin Pryzby <pryzby at telsasoft.com>
> wrote:
>
>> On Mon, Feb 12, 2018 at 11:33:05PM -0600, Dave Schmidt wrote:
>> > This is what I see in my terminal after 'sudo ipsec up test3' starting
>> > after IKE phase 1:
>> > XAuth authentication of '<userid>' (myself) successful
>> > IKE_SA TEST3[1] established between
>> > 192.168.1.34[192.168.1.34]...xxx.xxx.xxx.xxx[yyyyyy]
>> > scheduling reauthentication in 27855s
>> > maximum IKE_SA lifetime 28395s
>> > generating TRANSACTION response 1072426005 [ HASH CPA(X_STATUS) ]
>> > sending packet: from 192.168.1.34[4500] to xxx.xxx.xxx.xxx[4500] (76
>> bytes)
>> > assigning new lease to 'yyyyyyy'
>> > assigning virtual IP 10.1.30.1 to peer 'yyyyyyy'
>> > generating TRANSACTION request 420617457 [ HASH CPS(ADDR) ]
>> > sending packet: from 192.168.1.34[4500] to xxx.xxx.xxx.xxx[4500] (76
>> bytes)
>> > received packet: from xxx.xxx.xxx.xxx[4500] to 192.168.1.34[4500] (92
>> bytes)
>> > parsed INFORMATIONAL_V1 request 2093927451 [ HASH D ]
>> > received DELETE for IKE_SA TEST3[1]
>>
>> I'm not sure, but it looks like strongswan is (trying to) assign an
>> modecfg IP
>> to the peer (which thinks of itself as a "server" and expects to be the
>> one
>> doing the assigning).
>>
>> Do you need to set modecfg=pull?
>> leftsourceip=%config
>>
>> > If necessary I can share my ipsec.conf file.
>> I assume this would help.
>>
>> Justin
>>
>
>
>
> --
> GPG public key ID: 42AE9528
> http://www.openpgp.org/
>



-- 
GPG public key ID: 42AE9528
http://www.openpgp.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20180213/6205396d/attachment.html>


More information about the Users mailing list