[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