[strongSwan] Working simple setup was working, now no packets pass

James Lay jlay at slave-tothe-box.net
Tue Mar 3 03:50:32 CET 2015


On Mon, 2015-03-02 at 21:29 +0000, Peter Grandi wrote:

> > Server:
> > conn rw
> >         leftsubnet=192.168.1.0/24
> >         leftcert=StrongSwanHostCert.pem
> >         right=%any
> >         rightsourceip=192.168.1.11
> >         auto=add
> 
> > Client
> >  conn rw
> >         leftsourceip=192.168.1.11
> >         leftcert=mycert.pem
> >         right=ext.ip
> >         rightsubnet=.192.168.1.0/24
> >         rightid="C=CH, O=strongswan, CN=my.server.name
> >         auto=add
> 
> That does not make much sense... 'ipsec.conf' syntax is
> carefully designed to allow using exactly the same configuration
> file on both sides, even if rather regrettably several of the
> examples in the stronSwan docs are written differently for
> each side.
> 
> In IPsec there is really no client or server, that's why the two
> sides are called "left" and "right". They could be called "jim"
> and "sam" and perhaps that would be better.
> 
> Also note the syntax error in "rightsubnet=.192.168.1.0/24".
> 
> Also, you are stating that the client's source ip address is in
> the same subnet as the server's subnet, and the hosts in that
> subnet behind the gateway will not be sending response packets
> to that gateway because they will have a route telling them that
> 192.168.1.11 is on the same LAN as they are.
> 
> Also, since you are using private addresses with presumably
> public external IPs probably you should be using tunnel mode.
> 
> A connection that can be used on both sides might look like
> (entirely untested):
> 
> ----------------------------------------------------------------
> conn vpn
>   mode		=tunnel
>   auto		=ignore
> 
>   left		=PUBLICIP
>   leftsubnet	=192.168.1.0/24
>   rightsourceip	=192.168.2.0/24
>   leftid	="C=CH,O=strongSwan,CN=SERVERNAME"
>   leftcert	=SERVERNAME.pem
> 
>   # "client" configs should be as generic as possible.
>   # https://wiki.strongswan.org/projects/strongswan/wiki/VirtualIp
>   right		=%any
>   rightsourceip =%config
>   rightcert	=/etc/localcert.pem
> 
> conn vpn-this
>   also		=vpn
>   auto		=add
> 
> If you use a static 'rightsourceip' on the client regrettably
> you have to have different config files to explicitly specify
> that address on the client, and with the template structure
> above this is easy by writing:
> 
> ----------------------------------------------------------------
> conn vpn-CLIENTNAME
>   also		=vpn
>   auto		=add
>   rightsourceip	=192.168.2.11
> ----------------------------------------------------------------
> 
> as the second 'conn' only on the client. If you want to specify
> a host specific certificate for the client without using a
> generic host-independent location like '/etc/localcert.conf'
> you can use, again only on the client:
> 
> ----------------------------------------------------------------
> conn vpn-CLIENTNAME
>   also		=vpn
>   auto		=add
>   rightsourceip	=192.168.2.11
>   rightcrt	=CLIENTNAME.cert
> ----------------------------------------------------------------
> _______________________________________________
> Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users


Hi Peter,

Thanks for looking at this.  I was able to capture both a working and
non-working (ie tethered on a phone), and the results are interesting,
the broken one first:

19:31:06.778477 IP client.37489 > server.500: isakmp: parent_sa
ikev2_init[I]
19:31:07.319496 IP server.500 > client.37489: isakmp: parent_sa
ikev2_init[R]
19:31:07.485239 IP client.20855 > server.4500: NONESP-encap: isakmp:
child_sa  ikev2_auth[I]
19:31:07.703830 IP server.4500 > client.20855: NONESP-encap: isakmp:
child_sa  ikev2_auth[R]
19:31:11.489901 IP client.20855 > server.4500: NONESP-encap: isakmp:
child_sa  ikev2_auth[I]
19:31:11.491648 IP server.4500 > client.20855: NONESP-encap: isakmp:
child_sa  ikev2_auth[R]
19:31:18.687357 IP client.20855 > server.4500: NONESP-encap: isakmp:
child_sa  ikev2_auth[I]
19:31:18.688566 IP server.4500 > client.20855: NONESP-encap: isakmp:
child_sa  ikev2_auth[R]

And the working:

11:53:06.161554 IP client.500 > server.500: isakmp: parent_sa
ikev2_init[I]
11:53:06.244318 IP server.500 > client.500: isakmp: parent_sa
ikev2_init[R]
11:53:06.342298 IP client.4500 > server.4500: NONESP-encap: isakmp:
child_sa  ikev2_auth[I]
11:53:06.432252 IP server.4500 > client.4500: NONESP-encap: isakmp:
child_sa  ikev2_auth[R]
11:53:25.860119 IP client.4500 > server.4500: UDP-encap:
ESP(spi=0xcba88ac7,seq=0x1), length 132
11:53:25.860370 IP server.4500 > client.4500: UDP-encap:
ESP(spi=0xc14b8b11,seq=0x1), length 132
11:53:26.862885 IP client.4500 > server.4500: UDP-encap:
ESP(spi=0xcba88ac7,seq=0x2), length 132
11:53:26.863101 IP server.4500 > client.4500: UDP-encap:
ESP(spi=0xc14b8b11,seq=0x2), length 132
11:53:27.864142 IP client.4500 > server.4500: UDP-encap:
ESP(spi=0xcba88ac7,seq=0x3), length 132
11:53:27.864355 IP server.4500 > client.4500: UDP-encap:
ESP(spi=0xc14b8b11,seq=0x3), length 132
11:53:33.541948 IP client.4500 > server.4500: NONESP-encap: isakmp:
child_sa  inf2[I]
11:53:33.543699 IP server.4500 > client.4500: NONESP-encap: isakmp:
child_sa  inf2[R]

Just never quite establishes.  And again, keep in mind that this is the
exact same client and server, the only difference is working is on a
wireless network off site, and broken is tethered.  Pretty crazy.
Thanks again.

James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20150302/047601ff/attachment-0001.html>


More information about the Users mailing list