Hello NeoJedi
You should read and try to understand how the IKE-protocol (IKEv2 and/or IKEV1) negotiation works...refer to the RFC if possible
1. As part of the IKE negotiation between the 2 RV345P IPsec Peers, during the IKE-Auth negotitation, both the peers exchange the ID (Identifier) that are configured on each Peer (both LocalID and RemoteID). The ID values (IDi for initiator and IDr for responder) are exchanged in the ID-Payload of the IKE-Auth packet exchanges
2. Next point to note is that
a) By default if the user has explicitly NOT configured any IDs, then each of the PEERs ID will be the WAN-ipaddress...this by default
b) Else the User/administrator of the PeerGw can also configure other supported IDs such as FQDN (Fully-Qualified Domain Name), User-FQDN/UFQDN (which is always in the form of a email-id; for e.g rv345gw1@local.net and rv345gw2@remote.net)....these FQDNs/UFQDNs are NOT necessarily actual usable real fqdn/ufqdn/email-ids....its just the format...fqdn is just like a dns-name...rv345gw1.local.net/rv345gw2.remote.net
c) When using x509 RSA certs for authentication, the Local-ID/Remote-ID types with reference to Certificates would be
ASN1DN - in which case the value to provide would be the subject-field or the DistinguishedName/DN field in the respective certficate
FQDN: this would be in the subjectAltName of the Certificate in the form of a dns name (such as rv345gw1.local.net
UFQDN: this would again a email-id, in the subjectAltNamefield of the ceriticate in the form of admin@test.local, etc
3. So in your case in the first iteration when your s2s tunnel was working
a) Say on GW1 (with wanip: 67.177.25.114):
you had confgured as below:
Local-ID: Type-FQDN: cornerstone.hopto.org
RemoteID: Type-RemoteWanIP: 67.182.254.50
b) On GW2 (with wanip: 67.182.254.50):
you had correctly configured as below:
Local-ID: Type-IPAddress: 67.182.254.50
RemoteID: Type-FQDN: cornerstone.hopto.org
The IDs matched during the IKE negotiation and hence the tunnel was UP succesfully
4. Now what you have done is change the ID on ONLY GW1
a) On GW1 you have now configured as below by entering the dns-address of GW2, assuming that it will get resolved by the local-dns-server (configured on Gw1) to the the wan-ipaddress of the GW2 (67.182.254.50)
- say for example if your GW2 was represented by a dns-name such as "rv345gw2.europe.net"
Local-ID: Type-FQDN: cornerstone.hopto.org
RemoteID: Type-FQDN: rv345gw2.europe.net
- FYI, the FQDNs used in the IDs are never translated using dns...they are just used as string-values thats all...that is why i mentioned that the FQDN/UFQDN values used in this context need not be real values...only the type/format has to be followed...for e.g i could as well use a FQDN value such as "billgates.microsoft.net" or "president.whitehouse.us"....:-)
5. BUT you have NOT flipped/changed the IDs on the GW2 you are still configured on GW2 as below
Local-ID: Type-IPAddress: 67.182.254.50
RemoteID: Type-FQDN: cornerstone.hopto.org
- that is why you see on GW1 the below message after it has recieved a tunnel-initiation from GW2
2021-01-08T12:19:35-07:00 <info>charon: 12[CFG] looking for peer configs matching 67.177.25.114[cornerstone.hopto.org]...67.182.254.50[67.182.254.50]
The values in the square-brackets [] are the IDs that are set on the peers and sent in the ID-payload of IKE-protocol negotiation
6. So for your changes done on GW1 to work properly, on GW2, you have to configure as below:
Local-ID: Type-FQDN: rv345gw2.europe.net
RemoteID: Type-FQDN: cornerstone.hopto.org
-Br
