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