<div dir="ltr"><span class="gmail-m_-76818720825525875gmail-im">I tried enabling the unity option as shown below but I still get the same log output.<br></span><div><span class="gmail-m_-76818720825525875gmail-im">
<br>
</span>/etc/strongswan.d/charon.conf:<wbr>    # Send Cisco Unity vendor ID payload (IKEv1 only).<br>
/etc/strongswan.d/charon.conf:<wbr>    cisco_unity = yes<br>
/etc/strongswan.d/charon/unity<wbr>.conf:unity {<br>
/etc/strongswan.d/charon/unity<wbr>.conf-    load = yes<br><br></div><div>Here is what I see in my terminal after 'sudo ipsec up test3' :<br><br>initiating Aggressive Mode IKE_SA test3[1] to xxx.yyy.xxx.yyy<span class="gmail-im"><br>generating AGGRESSIVE request 0 [ SA KE No ID V V V V V ]<br></span>sending packet: from 192.168.1.34[500] to xxx.yyy.xxx.yyy[500] (396 bytes)<br>received packet: from xxx.yyy.xxx.yyy[500] to 192.168.1.34[500] (408 bytes)<br>parsed AGGRESSIVE response 0 [ SA KE No ID V V V NAT-D NAT-D V V HASH ]<br>received unknown vendor ID: 40:4b:f4:39:52:2c:a3:f6<br>received unknown vendor ID: 5b:36:2b:c8:20:f6:00:07<span class="gmail-im"><br>received NAT-T (RFC 3947) vendor ID<br></span>received DPD vendor ID<br>received XAuth vendor ID<span class="gmail-im"><br>local host is behind NAT, sending keep alives<br></span>generating AGGRESSIVE request 0 [ HASH NAT-D NAT-D ]<br>sending packet: from 192.168.1.34[4500] to xxx.yyy.xxx.yyy[4500] (108 bytes)<br>received packet: from xxx.yyy.xxx.yyy[4500] to 192.168.1.34[4500] (76 bytes)<br>parsed TRANSACTION request 375526604 [ HASH CPRQ(X_TYPE X_USER X_PWD) ]<br>generating TRANSACTION response 375526604 [ HASH CPRP(X_USER X_PWD) ]<br>sending packet: from 192.168.1.34[4500] to xxx.yyy.xxx.yyy[4500] (92 bytes)<br>received packet: from xxx.yyy.xxx.yyy[4500] to 192.168.1.34[4500] (92 bytes)<br>queueing INFORMATIONAL_V1 request as tasks still active<br>received packet: from xxx.yyy.xxx.yyy[4500] to 192.168.1.34[4500] (76 bytes)<br>parsed TRANSACTION request 1995451065 [ HASH CPS(X_STATUS) ]<br>XAuth authentication of 'dschmidt' (myself) successful<br>IKE_SA test3[1] established between 192.168.1.34[192.168.1.34]...<wbr>xxx.yyy.xxx.yyy[0017C56721AC]<br>scheduling reauthentication in 27800s<br>maximum IKE_SA lifetime 28340s<br>generating TRANSACTION response 1995451065 [ HASH CPA(X_STATUS) ]<br>sending packet: from 192.168.1.34[4500] to xxx.yyy.xxx.yyy[4500] (76 bytes)<br>parsed INFORMATIONAL_V1 request 3572062565 [ HASH N(INITIAL_CONTACT) ]<br>generating TRANSACTION request 3329385279 [ HASH CPRQ(ADDR DNS) ]<br>sending packet: from 192.168.1.34[4500] to xxx.yyy.xxx.yyy[4500] (76 bytes)<br>received packet: from xxx.yyy.xxx.yyy[4500] to 192.168.1.34[4500] (92 bytes)<br>parsed INFORMATIONAL_V1 request 184943178 [ HASH D ]<br>received DELETE for IKE_SA test3[1]<br>deleting IKE_SA test3[1] between 192.168.1.34[192.168.1.34]...<wbr>xxx.yyy.xxx.yyy[0017C56721AC]<br>initiating Aggressive Mode IKE_SA test3[2] to xxx.yyy.xxx.yyy<span class="gmail-im"><br>generating AGGRESSIVE request 0 [ SA KE No ID V V V V V ]<br></span>sending packet: from 192.168.1.34[500] to xxx.yyy.xxx.yyy[500] (396 bytes)<br>establishing connection 'test3' failed<br><br></div><div>Thanks,<br></div><div>Dave<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 13, 2018 at 7:33 AM, Dave Schmidt <span dir="ltr"><<a href="mailto:someguyfromiowa@gmail.com" target="_blank">someguyfromiowa@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div></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"><div><div class="gmail-h5"><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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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="gmail-m_7309221829237768715m_-2786266471725200008m_6665186262414354656HOEnZb"><font color="#888888"><br>
Justin<br>
</font></span></blockquote></div><br><br clear="all"><br></div></div><span class="gmail-">-- <br><div class="gmail-m_7309221829237768715m_-2786266471725200008m_6665186262414354656gmail_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>
</span></div></div></div>
</blockquote></div><br><br clear="all"><br>-- <br><div class="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>