RV340 Configuration Interface entering Remote Endpoint as FQDN

[fmarshall]

I've been making good progress deciphering the RV340 interface.  But there are a couple of things I'd like to understand:

In VPN / Client-to_Site Tunnel Group / 3rd Party Client / Advanced there is an entry for

Remote Endpoint with a  pulldown that includes "Static IP" and "FQDN".

I continue to be confused over IP addresses and "IDENTIFIERS" because they are presented using the same terms.

Anyway, an "endpoint" is a new term for me in the lexicon and I can't tell which it's supposed to be.

I believe I need to use the remote identifier FQDN that I'm using.

HOWEVER, when the entry is made:

Pull down "FQDN"

Enter a name like ccn.com

It will not accept the name!!  This is even though the name is accepted elsewhere in the RV340 settings.

Is this a bug?

Is this cockpit error?

Am I breaking some rule for these entries?

THANKS SO MUCH!!

[balaji.bandi]

Not sure what is the Firmware you running here. (i do not have a device to test)

but as per the document and emulator, it takes any FQDN.   (versions 1.0.3.X)

https://www.cisco.com/c/en/us/support/docs/smb/routers/cisco-rv-series-small-business-routers/smb5513-configure-a-site-to-site-virtual-private-network-vpn-connect.html

[fmarshall]

BB: Thanks for the response!

I'm running the latest firmware.  1.0.03.18.

When I say it doesn't take it, that's exactly what is happening.

The typical entry, if accepted, results in a blue-ish frame around the entry box.

If not accepted, results in a red frame around the entry box - which means it isn't going to "stick".

So, any suggestions?

This is a Client-to-Site configuration.  (I should have said so).  Nonetheless, I have reviewed the Site-toSite document you linked for context and learning the terms and labels being used.  This is about actual interface behavior and not about what  anything says it's supposed to do.

You say: "any FQDN".  Unfortunately, it seems that VPN implementations call entries various things:

Certainly if it's an "Identifier" (I'm not sure in this one setting WHAT it means because it uses a colloquial term "end point" and NOT the normal REMOTE IP ADDRESS or REMOTE IDENTIFIER. 

The FQDNs were are using are not "real" and, thus, not resolvable.  And, for that matter, can't be resolved in our lab with a pseudo publlic internet address space.  So, if the RV340 were connected to a live public IP address then maybe the settings behavior would be different.  Maybe it would say: "not resolvable".  But then, in that case we'd be screwed because the remote endpoint is a roaming user with many locations - so we can't use IP addresses for them.  Even so, I *have* experimented using the actual IP addresses in the lab to see if we can't make progress.  I'm getting close but no final success yet.

[fmarshall]

I have since learned through trial and error that there is ONE entry "Remote Endpoint" that applies apparently different, more stringent, rules to the structure of the names.  Heretofore, for years we have been using fvs_local.com and fvs_remote.com and I have been attempting to continue using the same IDs in the RV340 configuration.  However in Client-to-Site Tunnel/Group Settings in the Advanced Section, the Remote Endpoint entry will NOT ACCEPT those names.  This is apparently due to the underscore.  When the underscore is removed, the name is accepted there.  In all other entries of those names it works either way.  One might venture to suggest that this is a bug.  However, this one entry appears to be the only entry where the FQDN rules are more fully checked.  Underscores are not allowed in a formal FQDN.

[balaji.bandi]

after learning that. FQDN does not have any "_" nor I have seen godaddy offer that domain name with that.

so as per RFC the rule builds correctly, maybe it was accepted before, so new code will not take as it follows the proper process to look for name lookup.

glad you found a good point.

[nagrajk1969]

Dear Fmarshall

Just to pass on some info for reference, maybe you may know this already...but no harm done in repeating it

1. The Client-to-Site record/profile you create in the RV340 means you are creating a IPSec-VPN-Server for multiple remote-ipsec-clients to connect to this vpn-server

2. So in the advanced settings, the "Remote Endpoint" setting that you are refering to has 3 choices:

a) The default "Dynamic IP" - This means that the multiple Remote IPsec clients that will connect to your c2s-3rd-party-ipsec-vpn server will not be known to the server, and therefore this will configure the vpn server to accept connections from Any-IPaddress

- When you have 50 clients connecting to this VPN-server, obviously the vpn-server cannot be maintaining a list of ipaddresses of each of the clients to accept connection from....so its "dynamic-ip"

- Another reason for "Dynamic-IP" is that many of the remote ipsec-clients maybe connected behind a nat-router, or they will have a public-ip to internet which is thru DHCP/PPPoE which means dynamic-ipaddresses...hence the c2s-server is configured to accept "dynamic-ip" from different clients (1 or more than one...the limit is i think 50)

b) The next selection is "FQDN" which means a "Fully Qualified Domain Name" which would be usually and by standard means a complete dns-name-address of a remote--ipsec-client-host...it will be in the syntax "clienthostname.somedomain.com"

- the administrator of the vpn-server that means you, will select this option when you want to allow ONLY 1 remote-ipsec-client-host AND YOU DONT KNOW WHAT EXACTLY WILL BE THE IPADDRESS OF THE THIS SINGLE REMOTE-CLIENT...BUT YOU KNOW ITS DNS-FQDN-NAME which will always gets correctly resolved by using the dns-server configured on the RV340 to the actual active at-that time ipaddress of the client...

- this FQDN will be checked against a dns-server and once its resolved to a ipaddress (say for example 100.100.100.101), the vpn server will accept connection from ONLY that client that has this ipaddress in the src-address of the tunnel-connection packet recieved...

Note: NO Client-Host or any Host (other than web-servers and certain web-based application servers) which uses fqdn/dns to register their dynamically changing ipaddress will ever use fqdn as "domain.com",,,,"somedomain.net"....it has to be always a FQDN..a fully-qualified domain name...meaning the hostname portion should also be there...."hostname.somedomain.com" that is the proper and standard way to use....as far as i know and practice.

c) The 3rd selection is "Static IP" which is used for the same reason as point-b above,...BUT this time you know the ipaddress of the single client-pc that you want to allow to connect to this VPN-server...

As for the other settings related to FQDN/UFQDN/etc...its to do with Identifiers that are used in the IKE-negotiation between the IPsec-Peers....used in IKE-Auth negotiation phase...

When PSK is used for IKE-Auth there are 3 standard IDs that can be used by each of the IPSec-Peers and both will exchange their IDs during IKE-Auth process

1. ID-Type-1: FQDN

- Here only in this case you may use values such as gw1.local.net, servergw.test.net, corpHQ.net, server.net, etc...but i suggest it should be in the form of "hostname.somedomain.net"...this proper, rfc-standard method...

2. ID-Type-UFQDN; User-FQDN

- this will be always in the email-id syntax: client@gate.net, client@branch.local.net, etc

3. ID-Type: IPAddress

- This will always be the default ID that is used when the user/admin does not explicitly confiure any other ID

- this will always be by default the wan-ipaddress/pubic-ipaddress using which the IPsec-Peers will communicate with each other...

- very rarely do admins confiure a ipaddress which is NOT the wan-ipaddress

When Certificates are used for IKE-Autth, there are 3 IDs that could be used

1 ASN1DN: which will be the subject-field of the certificate used by that peer...its also called a Distinguised Name (DN)

2. FQDN : here it always would be the dns-address/fqdn that is present in the subjectAltName field of the certificate

3 UFQDN: here it will always be the email-id that is present in the subjecAltName field of the certficate used by the peer

hope this info is useful for future reference and further study....check out the RFC for IKEv2(and IKEv1 for comparison)