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