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 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 to xxx.xxx.xxx.xxx (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 to xxx.xxx.xxx.xxx (76 > bytes) > > received packet: from xxx.xxx.xxx.xxx to 192.168.1.34 (92 > bytes) > > parsed INFORMATIONAL_V1 request 2093927451 [ HASH D ] > > received DELETE for IKE_SA TEST3 > > 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/