cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1423
Views
5
Helpful
6
Replies

RV260W site to site VPN configuration with DynDNS

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!

 

 

 
1 Accepted Solution

Accepted Solutions

Richard Burts
Hall of Fame
Hall of Fame

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.

HTH

Rick

View solution in original post

6 Replies 6

Richard Burts
Hall of Fame
Hall of Fame

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.

HTH

Rick

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

 

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)...

 

https://www.cisco.com/c/en/us/support/docs/smb/routers/cisco-rv-series-small-business-routers/Configuring_Site-to-Site_VPN_on_the_RV160_and_RV260.html

Interesting, thanks for taking the time to reply.

 

From the link--

Configuring IKE Authentication Method

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

 

 

nagrajk1969
Spotlight
Spotlight


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

 

nagrajk1969
Spotlight
Spotlight

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