For testing the new connection you have to disable the legacy, however.
Yes, I totally understand that and that was done.
The are the authentication settings.
In local you define, how your server authenticates on the remote site.
And in remote you define, how the remote site has to authenticate on your server.
I think, it's necessary to state a local and a remote identifier in the pre-shared key settings. And then use the same in the local and remote settings of the connection. This is the only way, IPSec can select the proper PSK in case, you've multiple.
This means, you will have to enter the respective ID from the PSK in the authentication settings.
You only have the following in PSK setting:
Local Identifier Here I use my WAN IP.
Remote Identifier Here I use a Distinguished name (same as used in legacy Distinguished name and is a xxx.yyy.zz domain name)
Pre-Shared Key Our joint and unique PSK as set in both ends.
Type PSK
There is really no "Id" to specify here apart from Local and Remote identifier.
Recent versions set a unique requid automatically, as I've read. This didn't work in the past, however. So I've stated a unique one (above of 10) for each tunnel.
Ok, I will try that.
You should remove the check at default and select a proper for your needs here. The same is true for the phase 1.
According to your screenshot of the legacy settings, you need aes256-sha256-modp1024[DH2].
Done...
You mean in the new connections?
As mention, you have to state in the PSK and authentication settings.
In legacy you have
Phase 1 proposal (Authentication)
Authentication method Mutual PSK
My identifier <WAN IP>
Peer identifier Distinguished name an xxx.yy.xx domain address.
But I kind of have that in PSK settings, just in slightly different way
Local Identifier Here I use my WAN IP.
Remote Identifier Here I use a Distinguished name (same as used in legacy Distinguished name and is a xxx.yyy.zz domain name)
//Danne
Yes, I totally understand that and that was done.
The are the authentication settings.
In local you define, how your server authenticates on the remote site.
And in remote you define, how the remote site has to authenticate on your server.
I think, it's necessary to state a local and a remote identifier in the pre-shared key settings. And then use the same in the local and remote settings of the connection. This is the only way, IPSec can select the proper PSK in case, you've multiple.
This means, you will have to enter the respective ID from the PSK in the authentication settings.
You only have the following in PSK setting:
Local Identifier Here I use my WAN IP.
Remote Identifier Here I use a Distinguished name (same as used in legacy Distinguished name and is a xxx.yyy.zz domain name)
Pre-Shared Key Our joint and unique PSK as set in both ends.
Type PSK
There is really no "Id" to specify here apart from Local and Remote identifier.
Recent versions set a unique requid automatically, as I've read. This didn't work in the past, however. So I've stated a unique one (above of 10) for each tunnel.
Ok, I will try that.
You should remove the check at default and select a proper for your needs here. The same is true for the phase 1.
According to your screenshot of the legacy settings, you need aes256-sha256-modp1024[DH2].
Done...
You mean in the new connections?
As mention, you have to state in the PSK and authentication settings.
In legacy you have
Phase 1 proposal (Authentication)
Authentication method Mutual PSK
My identifier <WAN IP>
Peer identifier Distinguished name an xxx.yy.xx domain address.
But I kind of have that in PSK settings, just in slightly different way
Local Identifier Here I use my WAN IP.
Remote Identifier Here I use a Distinguished name (same as used in legacy Distinguished name and is a xxx.yyy.zz domain name)
//Danne
"