<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <br>
    <br>
    <div class="moz-cite-prefix">On 24/12/2020 15:34, Alex wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAB1R3shZw-B10Vd3AJ4=giWaCY4Mj23i=utEu2dwVpMo0DQBfg@mail.gmail.com">
      <pre class="moz-quote-pre" wrap="">
Hi,

</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">The win10 laptop I am using is connected to our internal network on
192.168.1.35. The libreswan server has a public IP (which I've
specified as the endpoint for the win10 client), but also is the
Internet gateway for the win10 client as 192.168.1.1. Is it possible
to connect to the libreswan server while being on the same internal
network?

Shouldn't you use an FQDN rather than IP with the FQDN matching your certificate SAN. Then, on your LAN fix the DNS server to map the FQDN to 192.168.1.1.
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
I'm not sure I understand. You're saying I should be using real
hostnames and DNS instead of just an IP address? Where specifically
should I be doing this?</pre>
    </blockquote>
    I don't know what I am talking about as I have never tried it, but
    the docs say to use an FQDN as the SAN when creating a certificate.
    I think it also says the FQDN must resolve to your server IP, so, if
    connecting to your LAN, the FQDN should resolve to your server LAN
    IP so you need to fix your internal DNS server. If connecting to
    your WAN, the FQDN should resolve to your WAN IP. This is controlled
    by your external DNS set up. If you then use the FQDN in Windows for
    the connection (if you can - you couldn't many, many moons ago),
    then everything resolves to the correct IP. It has nothing to do
    with your Libreswan settings.<br>
    <br>
    In Libreswan, I don't think it cares what the FQDN resolves to as
    you are using it as a text identity for leftid and the SAN.<br>
    <blockquote type="cite"
cite="mid:CAB1R3shZw-B10Vd3AJ4=giWaCY4Mj23i=utEu2dwVpMo0DQBfg@mail.gmail.com">
      <pre class="moz-quote-pre" wrap="">

In my windows.conf:

conn ikev2-cp
    left=68.195.111.42
    leftcert=vpn.mycompany.com
    <a class="moz-txt-link-abbreviated" href="mailto:leftid=@vpn.mycompany.com">leftid=@vpn.mycompany.com</a>

Is vpn.mycompany.com supposed to resolve to something or is it just a
label? If so, should it be the 68.195.111.42 address?

I believe the real problem is here:
Dec 24 10:26:32.076033: packet from 192.168.1.35:500:
ISAKMP_v2_IKE_SA_INIT message received on 68.195.193.42:500 but no
suitable connection found with IKEv2 policy
Dec 24 10:26:32.076091: packet from 192.168.1.35:500: responding to
IKE_SA_INIT (34) message (Message ID 0) with unencrypted notification
NO_PROPOSAL_CHOSEN

I've followed the directions described here to create a registry
entry. I've also now added the esp= and ike= lines referenced in this
doc, although it's unclear if that's what I was supposed to do, and it
still doesn't work.
<a class="moz-txt-link-freetext" href="https://libreswan.org/wiki/FAQ#Microsoft_Windows_connection_attempts_fail_with_NO_POROPOSAL_CHOSEN">https://libreswan.org/wiki/FAQ#Microsoft_Windows_connection_attempts_fail_with_NO_POROPOSAL_CHOSEN</a>

</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">FWIW an internal LAN of 192.168.1.0/24 or 192.168.0.0/24 is lousy for a roadwarrior as there is a high chance it will be the same as the local LAN he is connecting from, once he is on the road.
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
Yes, very true. This 192.168.1.0/24 network was created more than
twenty years ago. We're also using 192.168.6.0/24 for the mobile
workers, so hopefully that minimizes the potential for conflict.
</pre>
    </blockquote>
    <br>
  </body>
</html>