Am 6. Dezember 2016 23:38:31 MEZ, schrieb Damian McGuckin <dami...@esi.com.au>:
> On Tue, 6 Dec 2016, Robert Szasz wrote:
>
> > I'll try it, but that would be a problem if I have to add the local
> > address for any machine that wants to connect. I assume there is a
> way
> > to work through NAT because picked up nat-t and works for phase 1. I
> was
> > hoping I had just missed a parameter in the ipsec.conf to get phase
> 2
> > working.
>
> the NPPPD/IPSec combination does not need to know about the IP. Not
> knowing is the only way it can handle road-warrior types. The only
> issue
> as the far-more-knowledgeable-than-I Stuart Henderson pointed out is
> that
> you can have only one such Pre-Shared=-Key for all these unknown
> peers.
Guess I didn't stress it's just the ID
the client is most probably using
he should try. He could just skip
this part and go to figuring out how
to set a proper ID on his windows client.
>From `ipsec.conf(5)':
srcid string dstid string
[…] If srcid is omitted, the default is to use the IP address of the
connecting machine.
dstid is similar to srcid, but instead specifies the ID to be used by the
remote peer.
This section also shows how to handle
IDs like "b...@example.com".
>
> Sorry, busy with other things yesterday. I will try and find the time
> to
> go through your configurations later today.
>
> Did you try to use 3des and modp1024 in your ipsec.conf because that
> is
> the only config some Windows clients will handle? Did you read this?
>
> https://support.microsoft.com/en-us/kb/325158
>
If the windows client couldn't handle
the configured options the error message
would contain NO_PROPOSAL_CHOSEN.
Regards, Florian
