08-25-2021 04:58 PM - edited 08-25-2021 09:01 PM
Trying to establish a site to site VPN between two RV260Ws. Can't get it to work with Dyndns.
Dynamic IPs on both ends.
It will work if I substitute the current IP address in place for
Remote Group Setup
Remote LAN IP
xxx.xx.xx.xx
VS.
It will not work if I use either Remote FQDN or Remote User FQDN
Remote Group Setup
Remote FQDN
xxxx.dyndns.org
I can resolve the FQDN at either side correctly and dyndns is reporting out the correct IP addresses.
I currently have dynamic IPs on both ends and not static. Can't seem to figure out why it won't use the FQDN.
I also don't understand the difference between FQDN and User FQDN.
Any insights would be appreciated.
I could break it and put it back to FQDN and provide logs if helpful.
Thanks!
Solved! Go to Solution.
08-25-2021 10:20 PM
There is a well known issue with trying to do site to site vpn where both ends have dynamic IP on their outbound interfaces. The essence of the problem is that if the remote peer address is dynamic then the router does not know a specific IP address to which it should send the ISAKMP packet to negotiate the tunnel. If both ends are not sure of the peer address then clearly neither can initiate the vpn. If one end is dynamic and the other end is static then the vpn could work if the negotiation is initiated from the dynamic side. (if the dynamic side initiates the vpn then the static side receives the request and has the correct IP address to which it will respond).
It would seem logical that Dyndns could resolve this. But it does not. I am not authoritative about this and if someone in the community who is authoritative would join the discussion it would be nice. My sense is that Dyndns works for ping because it is a run time decision and the router is able to learn the current value of the address. But when used in the configuration it does not become a run time decision. So if both peers use dynamic IP addresses the vpn will not work.
08-25-2021 10:20 PM
There is a well known issue with trying to do site to site vpn where both ends have dynamic IP on their outbound interfaces. The essence of the problem is that if the remote peer address is dynamic then the router does not know a specific IP address to which it should send the ISAKMP packet to negotiate the tunnel. If both ends are not sure of the peer address then clearly neither can initiate the vpn. If one end is dynamic and the other end is static then the vpn could work if the negotiation is initiated from the dynamic side. (if the dynamic side initiates the vpn then the static side receives the request and has the correct IP address to which it will respond).
It would seem logical that Dyndns could resolve this. But it does not. I am not authoritative about this and if someone in the community who is authoritative would join the discussion it would be nice. My sense is that Dyndns works for ping because it is a run time decision and the router is able to learn the current value of the address. But when used in the configuration it does not become a run time decision. So if both peers use dynamic IP addresses the vpn will not work.
08-26-2021 08:54 AM
Rick,
Thank you for taking the time to reply. That helps a lot.
As you said, it seems like it would be able to resolve the dynamic IP address and use Dyndns. You can see in the logs that it is able to resolve the IP address and both sides are initially communicating but then it errors out.
I would be interested if someone has more insight on specifically why this can't work.
Thanks again Rick!
-Darin
08-26-2021 12:50 PM
Hello,
not sure what you are using as IKE authentication, but if you use pre-shared keys, try PKI certificates instead (the other option, as depicted in the link below)...
08-26-2021 01:10 PM
Interesting, thanks for taking the time to reply.
From the link--
Step 1. Select either Pre-shared Key or Certificate. For this demonstration, we will be selecting Pre-shared Key as our IKE authentication method.
IKE peers authenticate each other by computing and sending keyed hash of data that includes the pre-shared key. If the receiving peer is able to create the same hash independently using its pre-shared key, it knows that both peers must share the same secret, thus authenticating the other peer. Pre-shared keys do not scale well because each IPsec peer must be configured with the pre-shared key of every other peer with which it establishes a session.
The digital certificate is a package that contains information such as a certificate bearer’s identify: name or IP address, the certificate’s serial number, the certificate’s expiration date, and a copy of certificate bearer’s public key. The standard digital certificate format is defined in the X.509 specification. X.509 version 3 defines the data structure for certificates. If you have selected Certificate, make sure your signed certificate is imported in Administration > Certificate. Select the certificate from the drop-down list for both local and remote.
_____
I am using the pre-share key. You can see in the log messages that it's getting an error matching the hash data, I'm assuming to match the pre-shared keys.
I'm less familiar with certificates and how they would help, but will look into it.
Thanks again.
-Darin
08-27-2021 03:04 PM
Hello Darin
The below is what need to configure to make it work
1. Config for S2S tunnel to RV260-SITE1
--------------------------
In Basic Settings Tab
---------------------------
Enable: Yes(enable checkbox)
Connection Name: toSite2
IPSec Profile: IKEv2-Profile
Interface: WAN
Remote Endpoint: FQDN : enter dyndns fqdn of RV260-site2
Note: Replace the fqdn value here with your actual dyndns-registered fqdn
Local IKE Authentication Method:
Pre-Shared-Key: Test$123456789
Remote IKE Authentication Method:
Pre-Shared-Key: Test$123456789
Local Group Setup:
Local ID Type: Local FQDN
Local Identifier: rv260gw.site1.local
Local IP Type: Subnet
IP Address: 192.168.1.0
Subnet Mask: 255.255.255.0
Remote Group Setup:
Remote ID Type: Remote FQDN
Remote Identifier: rv260gw.site2.local
Remote IP Type: Subnet
IP Address: 192.168.2.0
Subnet Mask: 255.255.255.0
------------------------
In Advanced Settings Tab
-------------------------
Non-RFC Compliant: Disable/Unchecked
Compress: Disable/Unchecked
Netbios Broadcast: Disable/Unchecked
Keepalive: Disabled/Unchecked
DPD Enable: Yes (Checked/Enable)
- Delay Time:10s
- Detection Timeout: 30s
- Delay Action: clear
2. Config for S2S tunnel to RV260-SITE2
--------------------------
In Basic Settings Tab
---------------------------
Enable: Yes(enable checkbox)
Connection Name: toSite1
IPSec Profile: IKEv2-Profile
Interface: WAN
Remote Endpoint: FQDN : enter dyndns fqdn of RV260-site1
Note: Replace the fqdn value here with your actual dyndns-registered fqdn
Local IKE Authentication Method:
Pre-Shared-Key: Test$123456789
Remote IKE Authentication Method:
Pre-Shared-Key: Test$123456789
Local Group Setup:
Local ID Type: Local FQDN
Local Identifier: rv260gw.site2.local
Local IP Type: Subnet
IP Address: 192.168.2.0
Subnet Mask: 255.255.255.0
Remote Group Setup:
Remote ID Type: Remote FQDN
Remote Identifier: rv260gw.site1.local
Remote IP Type: Subnet
IP Address: 192.168.1.0
Subnet Mask: 255.255.255.0
------------------------
In Advanced Settings Tab
-------------------------
Non-RFC Compliant: Disable/Unchecked
Compress: Disable/Unchecked
Netbios Broadcast: Disable/Unchecked
Keepalive: Disabled/Unchecked
DPD Enable: Yes (Checked/Enable)
- Delay Time:10s
- Detection Timeout: 30s
- Delay Action: clear
3. Now apply/save on both routers...
4. Note: For IKEv1-based tunnel
a) The config all remains the same (except that you will be configuring only one PSK value in the GUI, instead of 2 for IKEv2)
b) And "ONLY In case the tunnel still does not come up with IKEv1", keep the same configs as it is, BUT additionally also enable "Aggressive Mode" on both Routers S2S config pages
- Aggressive Mode checkbox will be present when IKEv1 is used
- and it will be there in either the Basic-Settings page (at the bottom) or in Advanced settings tab)
Hope it works for you too
08-27-2021 03:22 PM
Hello Darin
And below config is what you need to apply when you use User-FQDN for Local-ID/Remote-IDs
Notes:
a) The Local-ID and Remote-ID is used in the IKE Protocol negotiation (IKEv1 and/or IKEv2) between the 2 IPsec peers
- The ID-types used by IKE are
* IPaddress (this is default wan-ipaddresses if not explicitly configured with some other ipaddrs)
* FQDN (Fully Qualified Domain Name) which can be any dns-fqdn name you can make-up/construct yourselves as custom values
- generally by standard and as standard recommended practice, with PSK-auth, the fqdns-values used in Local-ID/Remote-ID are never the FQDNs/dns-names of the wan-interfaces of the Routers (like your registered dyndns-org fqdns)
- the reason being that these IDs are used/exchanged during the IKE protocol negotiation and are independent of the actual wan-interface FQDN/DNS-NAME of the routers...so therefore the values could be any custom fqdn/dns-name
* User-FQDN (U-FQDN) is by standard in email-address format, so you could use any value that you can makeup/construct as custom value
(such as "rv260gw@site1.local" and/or "rv260gw@site2.local" or "adam@site.local" and/or "bob@site.local" and/or "router1@acme.com" and/or "router2@acme.com", etc)
- the email-addresses used here in these Local/Remote-IDs need-not be and definitely should not be any active valid email-addresses
1. Config for S2S tunnel to RV260-SITE1
--------------------------
In Basic Settings Tab
---------------------------
Enable: Yes(enable checkbox)
Connection Name: toSite2
IPSec Profile: IKEv2-Profile
Interface: WAN
Remote Endpoint: FQDN : enter dyndns fqdn of RV260-site2
Note: Replace the fqdn value here with your actual dyndns-registered fqdn
Local IKE Authentication Method:
Pre-Shared-Key: Test$123456789
Remote IKE Authentication Method:
Pre-Shared-Key: Test$123456789
Local Group Setup:
Local ID Type: Local UFQDN
Local Identifier: rv260gw@site1.local
Local IP Type: Subnet
IP Address: 192.168.1.0
Subnet Mask: 255.255.255.0
Remote Group Setup:
Remote ID Type: Remote UFQDN
Remote Identifier: rv260gw@site2.local
Remote IP Type: Subnet
IP Address: 192.168.2.0
Subnet Mask: 255.255.255.0
------------------------
In Advanced Settings Tab
-------------------------
Non-RFC Compliant: Disable/Unchecked
Compress: Disable/Unchecked
Netbios Broadcast: Disable/Unchecked
Keepalive: Disabled/Unchecked
DPD Enable: Yes (Checked/Enable)
- Delay Time:10s
- Detection Timeout: 30s
- Delay Action: clear
2. Config for S2S tunnel to RV260-SITE2
--------------------------
In Basic Settings Tab
---------------------------
Enable: Yes(enable checkbox)
Connection Name: toSite1
IPSec Profile: IKEv2-Profile
Interface: WAN
Remote Endpoint: FQDN : enter dyndns fqdn of RV260-site1
Note: Replace the fqdn value here with your actual dyndns-registered fqdn
Local IKE Authentication Method:
Pre-Shared-Key: Test$123456789
Remote IKE Authentication Method:
Pre-Shared-Key: Test$123456789
Local Group Setup:
Local ID Type: Local UFQDN
Local Identifier: rv260gw@site2.local
Local IP Type: Subnet
IP Address: 192.168.2.0
Subnet Mask: 255.255.255.0
Remote Group Setup:
Remote ID Type: Remote UFQDN
Remote Identifier: rv260gw@site1.local
Remote IP Type: Subnet
IP Address: 192.168.1.0
Subnet Mask: 255.255.255.0
------------------------
In Advanced Settings Tab
-------------------------
Non-RFC Compliant: Disable/Unchecked
Compress: Disable/Unchecked
Netbios Broadcast: Disable/Unchecked
Keepalive: Disabled/Unchecked
DPD Enable: Yes (Checked/Enable)
- Delay Time:10s
- Detection Timeout: 30s
- Delay Action: clear
3. Now apply/save on both routers...
4. Note: For IKEv1-based tunnel
a) The config all remains the same (except that you will be configuring only one PSK value in the GUI, instead of 2 for IKEv2)
b) And "ONLY In case the tunnel still does not come up with IKEv1", keep the same configs as it is, BUT additionally also enable "Aggressive Mode" on both Routers S2S config pages
- Aggressive Mode checkbox will be present when IKEv1 is used
- and it will be there in either the Basic-Settings page (at the bottom) or in Advanced settings tab)
Hope it works for you too
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide