<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/4.6.6">
</HEAD>
<BODY>
On Mon, 2015-03-02 at 21:29 +0000, Peter Grandi wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#737373">> Server:</FONT>
<FONT COLOR="#737373">> conn rw</FONT>
<FONT COLOR="#737373">>         leftsubnet=192.168.1.0/24</FONT>
<FONT COLOR="#737373">>         leftcert=StrongSwanHostCert.pem</FONT>
<FONT COLOR="#737373">>         right=%any</FONT>
<FONT COLOR="#737373">>         rightsourceip=192.168.1.11</FONT>
<FONT COLOR="#737373">>         auto=add</FONT>

<FONT COLOR="#737373">> Client</FONT>
<FONT COLOR="#737373">>  conn rw</FONT>
<FONT COLOR="#737373">>         leftsourceip=192.168.1.11</FONT>
<FONT COLOR="#737373">>         leftcert=mycert.pem</FONT>
<FONT COLOR="#737373">>         right=ext.ip</FONT>
<FONT COLOR="#737373">>         rightsubnet=.192.168.1.0/24</FONT>
<FONT COLOR="#737373">>         rightid="C=CH, O=strongswan, CN=my.server.name</FONT>
<FONT COLOR="#737373">>         auto=add</FONT>

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.
  # <A HREF="https://wiki.strongswan.org/projects/strongswan/wiki/VirtualIp">https://wiki.strongswan.org/projects/strongswan/wiki/VirtualIp</A>
  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
<A HREF="mailto:Users@lists.strongswan.org">Users@lists.strongswan.org</A>
<A HREF="https://lists.strongswan.org/mailman/listinfo/users">https://lists.strongswan.org/mailman/listinfo/users</A>
</PRE>
</BLOCKQUOTE>
<BR>
Hi Peter,<BR>
<BR>
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:<BR>
<BR>
<TT>19:31:06.778477 IP client.37489 > server.500: isakmp: parent_sa ikev2_init[I]</TT><BR>
<TT>19:31:07.319496 IP server.500 > client.37489: isakmp: parent_sa ikev2_init[R]</TT><BR>
<TT>19:31:07.485239 IP client.20855 > server.4500: NONESP-encap: isakmp: child_sa  ikev2_auth[I]</TT><BR>
<TT>19:31:07.703830 IP server.4500 > client.20855: NONESP-encap: isakmp: child_sa  ikev2_auth[R]</TT><BR>
<TT>19:31:11.489901 IP client.20855 > server.4500: NONESP-encap: isakmp: child_sa  ikev2_auth[I]</TT><BR>
<TT>19:31:11.491648 IP server.4500 > client.20855: NONESP-encap: isakmp: child_sa  ikev2_auth[R]</TT><BR>
<TT>19:31:18.687357 IP client.20855 > server.4500: NONESP-encap: isakmp: child_sa  ikev2_auth[I]</TT><BR>
<TT>19:31:18.688566 IP server.4500 > client.20855: NONESP-encap: isakmp: child_sa  ikev2_auth[R]</TT><BR>
<BR>
And the working:<BR>
<BR>
<TT>11:53:06.161554 IP client.500 > server.500: isakmp: parent_sa ikev2_init[I]</TT><BR>
<TT>11:53:06.244318 IP server.500 > client.500: isakmp: parent_sa ikev2_init[R]</TT><BR>
<TT>11:53:06.342298 IP client.4500 > server.4500: NONESP-encap: isakmp: child_sa  ikev2_auth[I]</TT><BR>
<TT>11:53:06.432252 IP server.4500 > client.4500: NONESP-encap: isakmp: child_sa  ikev2_auth[R]</TT><BR>
<TT>11:53:25.860119 IP client.4500 > server.4500: UDP-encap: ESP(spi=0xcba88ac7,seq=0x1), length 132</TT><BR>
<TT>11:53:25.860370 IP server.4500 > client.4500: UDP-encap: ESP(spi=0xc14b8b11,seq=0x1), length 132</TT><BR>
<TT>11:53:26.862885 IP client.4500 > server.4500: UDP-encap: ESP(spi=0xcba88ac7,seq=0x2), length 132</TT><BR>
<TT>11:53:26.863101 IP server.4500 > client.4500: UDP-encap: ESP(spi=0xc14b8b11,seq=0x2), length 132</TT><BR>
<TT>11:53:27.864142 IP client.4500 > server.4500: UDP-encap: ESP(spi=0xcba88ac7,seq=0x3), length 132</TT><BR>
<TT>11:53:27.864355 IP server.4500 > client.4500: UDP-encap: ESP(spi=0xc14b8b11,seq=0x3), length 132</TT><BR>
<TT>11:53:33.541948 IP client.4500 > server.4500: NONESP-encap: isakmp: child_sa  inf2[I]</TT><BR>
<TT>11:53:33.543699 IP server.4500 > client.4500: NONESP-encap: isakmp: child_sa  inf2[R]</TT><BR>
<BR>
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.<BR>
<BR>
James
</BODY>
</HTML>