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 <pry...@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/

Reply via email to