RV345P Log Errors & Dropping WAN connection Intermittantly

[Douglas Byrne]

Hi,

Having a recurring issue where periodically the router drops the WAN connection to the Cable Modem.

The Cable Modem is in Bridge Mode and has a dynamic IP Address

We have via a Dynamic DNS service a DynamicDNS.com address for this router as it is part of a site-to-site VPN with another location that has a Static IP.

Firmware: 1.0.03.22

Smart Software Licensing Status
"Registered"
"Authorized"

Pattern we typically see is:

2021-10-09T00:49:11-04:00 <error>ddns: wan1:unable to resolve DYNAMICDNSADDY.com.
2021-10-09T00:48:49-04:00 <error>dnsmasq: failed to parse lease database cleanly
2021-10-09T00:48:49-04:00 <error>dnsmasq: failed to allocate -1 bytes

Router drops Internet connectivity to all connected devices for a couple of minutes and then regains connectivity.

Also seeing a bunch of Cisco Licensing cloud errors but not sure they are having any impact.

Anyone else experiencing this issue and are there any resolutions?

We have at our other site an RV345P almost identically configured except it has static IP address behind a cable modem in bridge mode and on that router we DO NOT have these type of errors.

EXPANDED LOG OUTPUT Attached as a text file as dumping it in the message appears to flag the post.

[nagrajk1969]

Hi

For a similar situation (of wan interfaces going down often) experienced by another community-member, i had suggested a "possible solution" that could be applied to solve the wan-interface fluctuations. Kindly please refer to the discussion in below link and apply the same steps of "disabling the Network-Service-Detection completely or pointing it to a "Remote-Host" instead of "default-gateway

https://community.cisco.com/t5/small-business-routers/cisco-rv340-router44808b-wan-interface-continuously-down-and-up/m-p/4477590#M41968

Note: You could also collect more detailed logs if you offload/send your logs to a syslog-server in your lan (to a linux-syslog-server), and then you can also dynamically check/capture the logs on the syslog-server (instead of on the router) - say using "tail -f /var/log/syslog"

Hope this is of some help

thanks & best wishes

[Douglas Byrne]

Nagrajk,

Applied your suggestion to the Multi-Wan Settings (Fully Disabled NSD) and continue to experience the WAN dropping and the error about DDNS not being able to resolve our DDNS name.

Reviewed all the Dynamic DNS settings and there does not seem to be anything there that could/would be misconfigured.

(Did notice we are using Cloudflare DNS servers (1.1.1.1 and 1.0.0.1) as opposed to the ISPs but doubt that would be causing issues)

Also set up KIWI syslog server but appears to be getting the same messages we are able to pull of the RV345 itself (ie not providing any addition detail on the errors we see in the RV logs).

Any other suggestions?

[Douglas Byrne]

Nagrajk,

Thanks for pointing me to that post, plan to apply the change you suggest (specifically disabling NSD as we only have one internet connection at that site) and monitor over the next few days.

Will update this post with the results (fingers crossed this addresses the issue).

Again, thank you for your guidance.

[nagrajk1969]

Hi

1. Yes, keep the NSD(Network Service Detection) disabled completely.

- just to confirm (you may have done it already), after disabling NSD on the wan1 interface, did you do a reboot (after a permanent-save to startup-config)?...

2. As for the wan interface "going down"....no i dont think its going down at all especially not after NSD is disabled).....its my personal opinion based on my understanding of how the wan-interface/configurations work on RV34X routers (i have a few in my network-deployment using DDNS too...so i know something about it i guess

a) the issue with DDNS/dns-resolutions does not mean that its happening becos of "wan1 interface going down"...

- dns/ddns-issues and wan1-interface links are independent

------------------------------------------------------------------------

Lets analyse this by breaking up the network-deployment of your RV345 into 2 parts of your configuration on the RV345

1. The wan1 interface configuration:

>>>The Cable Modem is in Bridge Mode and has a dynamic IP Address

- Can you please confirm as whether the "dynamic-ipaddress" that is assigned to your wan1 interface is via DHCP or have you configured a PPPoE on wan1?

- Can you please confirm that you have NOT configured "wan" interface as a vlan-subinterface on this wan1? (some of the ISPs require that the "wan" is configured on a vlan-subinterface) 

a) Is the "dynamic-ip" address assigned to your wan1 interface a "Public-IPaddress" or does it fall into either of the below private-address-subnets:

10.0.0.0/8 (so it would be something like 10.x.x.x on your wan1 interface, if it is so)

172.16.0.0/12 (so it would be something like 172.16.x.x on your wan1 interface, if it is so)

192.168.0.0/16 (so it would be something like 192.168.x.x on your wan1 interface, if it is so)

b) Now when you configure your wan1 for dynamic-ipaddressing, you also have a choice of configuring the "dns-servers" which would be

- either you will configure the dns-server ipaddresses them explicitly in this wan config

- or you will use whatever is assigned by your ISP (thru DHCP or with your PPPoE connection)

>>>(Did notice we are using Cloudflare DNS servers (1.1.1.1 and 1.0.0.1)

>>>as opposed to the ISPs but doubt that would be causing issues)

- And so as you mentioned in your statement, instead of getting the dns-ipaddresses from your ISP, you have explicitly configured the Cloudfare-DNS servers - 1.1.1.1 and 1.0.0.1. This is absolutely fine and correct

c) And you have also "disabled/unchecked" the NSD service/feature on the wan1 interface under WAN/MultiWAN

d) So as far as the wan configuration is concerned, the above is what that can be done, and your deployment would look something like below:

Notes:

- At this point of time....iam assuming that the DDNS service (that is a separate service further down in the GUI)  is disabled at this time...i suggest that you should do a debug by configuring upto this point and "disable/uncheck" the ddns service, if any, on the wan1 interface

lan-host1---vlan1[RV345]wan1----[modem]----[isp-router]----{internet}---[cloud-fare-dns-servers]---[example-google-8.8.8.8]

- iam assuming that your lan-host is configured as below:

ipaddress: 192.168.1.x/24

default-gateway ipaddress: 192.168.1.1 (which is the ipaddress of the vlan1 interface of RV345)

e) Next for the purpose of debugging, in the "Firewall basic settings page" , uncheck/disable "Block-wan-requests" (this will enable pings to your wan1 ipaddress from wan-hosts, else its disabled by default). Do a apply-and-permanent-save-to-startup-config.

f) So now at this point of debugging, i would suggest you do the below steps:

step-1: reboot the RV345 (after you have ensured that you have done a apply-permanent-save-to-startup-config of above configs)..and wait for about 180-seconds

step-2: Next, after the reboot, try the below

- send 20 pings, as "ping 192.168.1.1 -c 20" ...it will be and it should be successful

- next send 20 pings as "ping 1.1.1.1 -c 20" and/or "ping 1.0.0.1 -c 20".....here the point is that if wan1 interface-config is working correctly, then the pings from the lan-host1 will get correctly routed to the internet upto the cloudfare-dns-servers and the ping-replies will be successfully recieved by the lan-host1. If this is not working...then to double-check further,

- you should also send 20 pings to "ping 8.8.8.8 -c 20" to the always-on-reachable google-dns-server 8.8.8.8

so if the pings from lan-host1 to 8.8.8.8 (or any other internet-hosts) work, then it means your wan1 link(and confgs) are working correctly...

- in case you dont see any ping replies from 1.1.1.1/1.0.0.1, it maybe also becos they have blocked ping-replies

So at this config-stage, i would request that you post the screenshots of your configurations on the RV345

--------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------

2. The second part (independent of wan) is your DDNS service config:

a) Here iam assuming that you have registered to one of the 4 supported ddns-service....

- the RV345 has these 4 DDNS-service-clients supported

b) Now using one of the ddns-client (say dyndns for example), you will be registering your DDNS FQDN (rv345gw.yourdomain.com) to the dyndns-servers on the internet....AND alongwith with your fqdn, the RV345-ddns-client will be sending the active wan1 ipaddress for mapping the fqdn to the ipaddress as below in the dyndns-server records for your account

rv345gw.dyndns.org <your-wan1-ipaddress-assingned-by-your-isp>

c) Check the attached screenshots for reference

d) So please kindly post your DDNS configuration screenshots that you have applied

--------------------------------------------------------------------------

So now some Additional notes:

1. When a remote-wan-host (or from your s2s-vpn peergw) say for example sends a Ping to your ddns-registered fqdn (representing your RV345-wan) for example "rv345gw.dyndns.org" , then this fqdn will be 

- first resolved by the dydns-dns-servers to the registered ipaddress in its records....

- and this ipaddress MUST be a public-ipaddress that is active on the RV345-wan1 interface....

- if the ipaddress is in private-address-space (as mentioned above initially), it cannot be reached or routed from the internet/wan-hosts

PS: I truly hope that iam not conveying anything of the sort of "being Patronizing" to you. Iam truthfully not being patronizing...the above is always the way i go about debugging any issue...however childish or patronizing it may look like...so please dont mind all of the above points/statements....its just to do with debugging in a more focussed manner so that we can eliminate the areas of contention as we go about debugging

thanks

[Douglas Byrne]

Firstly, greatly appreciate all of your suggestions and the tone and cadence is just fine!

Let me respond to some of your questions and will proceed to implement some of the testing and config changes proposed.

1. Yes, Full Permanent Save and reboot of Router and all hosts after NSD was disabled.
2. Interesting thought here that the WAN interface is not dropping.

(If this is the case, what would cause all hosts to lose internet connectivity for ~3 mins every time we see the DDNS error of not being able to resolve RV345.DNYDNS.com? - Just assumed it was a WAN connectivity loss)

Curious to trouble shoot more specifically the DYNDNS issues.

Second Section

1. Yes, Cable Modem is in Bridge mode with a publicly routable dynamic IP Address from the ISP (I will call and triple check they did not propagate out any changes to their equipment)

- Yes, the dynamic IP from ISP is assigned via DHCP (that is the config selection on WAN 1 - NOT PPoE).

- NO vlan sub interface on WAN 1

Just a Note: IPv6 is "disabled" and on Advanced Tab MTU is set to "Auto" Radio button.

1. A) The ISP assigned dynamic IP is a publicly routable address and when you ping the dyndns "rv345.dyndns.com" it will resolve to that public dynamic IP but not return pings as ICMP reply is disabled.  Also the Site2Site is using that dyndns to establish and maintain tunnel connection from another ISP that is supplying bandwidth at our other site.

1. B) We manually set our DNS servers to Cloudflare to match all other routers across our environments. Under the WAN 1 tab we have "Use DNS as Below" and

Static DNS 1: 1.1.1.1

Static DNS 2: 1.0.0.1

1. C) Correct NSD is totally greyed out and the check box for "enable network service detection" is UNCHECKED.

To your question about DDNS under WAN/Dynamic DNS settings we have

WAN 1

Enable This Dynamic DNS Policy "Enable is Checked"

Provider: DynDNS.com

UN

PW

FQDN: rv345.dyndns.com (not our actual FQDN)

Send Updates to Dyn DNS Provider "Enable Checked" "Every 30 Mins" from drop down

1. D) Yes LAN host is 192.168.X.Y

Default Gateway is 192.168.X.1

Yes, VLAN1 is 192.168.X.Y

Let me follow your debugging suggestions and disable the DDNS and run some continuous ping tests and will double/triple apply the configs and ensure a Save, Apply to startup config and Reboot is performed again and report back with what we find.

Again, thanks for taking the time and sharing these suggestions.

[nagrajk1969]

also ensure that the time and date on your RV34X router is set to present date and time...

[Douglas Byrne]

Ok, still have the WAN connectivity dropping once or twice daily.

It has gotten better (ie less frequent) and keep noticing an SSLVPN error that seems to kick off the process where all devices connected to the RV345 end up losing internet connectivity and takes a few minutes for the internet connectivity to be re-established.

Here is the error that seems to start the process:

2021-10-26T10:15:25-04:00 <error>log_sslvpnac: facility=SslVpn;msg=ERROR sslserver.c.2740[76F66300] sslserver_init: Error setting SO_REUSEADDR socket option;

We are seeing this error during time periods where no users were attempting an SSL connection.

Any thoughts on what is causing this and looking at the log below, does this appear to be the root cause of the process that eventually causes internet connectivity to drop?

Log errors we see that lead up to the DDNS error which is indicative of our internet connectivity loss:

2021-10-26T10:16:12-04:00 <error>ddns: wan1:unable to resolve ROUTERNAME.dyndnsurl.com.
2021-10-26T10:15:51-04:00 <error>dnsmasq: failed to parse lease database cleanly
2021-10-26T10:15:51-04:00 <error>dnsmasq: failed to allocate -1 bytes
2021-10-26T10:15:41-04:00 <error>dnsmasq: failed to parse lease database cleanly
2021-10-26T10:15:41-04:00 <error>dnsmasq: failed to allocate -1 bytes
2021-10-26T10:15:34-04:00 <error>dnsmasq: failed to parse lease database cleanly
2021-10-26T10:15:34-04:00 <error>dnsmasq: failed to allocate -1 bytes
2021-10-26T10:15:25-04:00 <error>log_sslvpnac: facility=SslVpn;msg=ERROR sslserver.c.2740[76F66300] sslserver_init: Error setting SO_REUSEADDR socket option;

Another Example:

2021-10-25T23:31:03-04:00 <error>ddns: wan1:unable to resolve ROUTERNAME.dyndnsurl.com.
2021-10-25T23:30:41-04:00 <error>dnsmasq: failed to parse lease database cleanly
2021-10-25T23:30:41-04:00 <error>dnsmasq: failed to allocate -1 bytes
2021-10-25T23:30:31-04:00 <error>dnsmasq: failed to parse lease database cleanly
2021-10-25T23:30:31-04:00 <error>dnsmasq: failed to allocate -1 bytes
2021-10-25T23:30:25-04:00 <error>dnsmasq: failed to parse lease database cleanly
2021-10-25T23:30:25-04:00 <error>dnsmasq: failed to allocate -1 bytes
2021-10-25T23:30:16-04:00 <error>log_sslvpnac: facility=SslVpn;msg=ERROR sslserver.c.2740[76FC4300] sslserver_init: Error setting SO_REUSEADDR socket option;

Any thoughts or guidance, greatly appreciated.

[nagrajk1969]

Hi

some queries from me:

1. Have you enabled and configured the AnyConnect SSL-VPN server on the RV345?

2. If yes, what/which certificate are you using/applied on this sslvpn server?

3. Have you also enabled dhcpv6-server too on the lan/vlanX-interfaces of the RV345?, if yes and if you are not using it, disable the dhcpv6-server(s)

[Douglas Byrne]

1. Yes, we have configured the AnyConnect SSL-VPN Server (Specifically VPN Tab - SSL VPN Settings)

2. Under the SSL VPN Settings it has the certificat listed as "default" from the drop down and we are NOT currently using any 3rd party certificate.

3. IPv6 is disabled on all VLANs

On this particular device there are only 2 SSL-VPN users and they have no trouble connecting via anyconnect.  That said, neither have attempted to remotely access this device in 2 weeks that is to say, the errors would not be caused by a connection attempt from the users.

[nagrajk1969]

Hi

>>>On this particular device there are only 2 SSL-VPN users and they have no trouble connecting via anyconnect. 

Yes...generally....generally/ideally it is expected to work when the "default" cert is also used to configure the sslvpn-server

>>>That said, neither have attempted to remotely access this device in 2 weeks that is to say, the errors would not be caused by a >>>connection attempt from the users.

- Yes. BUT looking at the sslvpn "errors" logs posted by you...i am trying to eliminate the possibilities to arrive at  some root-cause for this happening on your RV345-router

- so i was thinking if its not much trouble for you, could you do the below steps on the RV345 and do a apply-permanent-save & reboot once, and then observe?

a) Check and confirm that the date & time on the router is set to present date/time in your timezone. 

b) In the Adminsitration/Certificates, generate a new sample "self-signed-certificate" as shown in attached screenshot...you please change it to your country and other details...etc

c) and then go to the VPN/SSLVPN server config page and select this new self-signed-certificate instead of the "default"...and do a apply-and-permanent-save-to-startup....and do a reboot once

d) If all things work fine...fingers-crossed, it is expected that you should not be seeing any of the ssl-vpn errors/logs...especially when there are no users/clients connecting.....

- Now as for the logs showing ddns errors...you need to check and ensure that the dyndns ddns client is connecting and updating to your dyndns-account correctly and properly

- are you capturing the logs on a syslog server in your rv345-lan-network.???...if not...do it....

[Douglas Byrne]

Nagrajk - again, appreciate your attention and replies here.

Got some time to play with this environment today.

First in reponse to your questions/guidance:

A. Confirmed, RV345 has correct date and time (pointed to a time server if memory serves me)

B. Followd your advice about generating a self-signed cert (did and appled that to the VPN), then....realized I had a few unused SSL Certs in a Godaddy account (regretting I remembered those! Process took a bit out of my afternoon)

- Did the CSR off the RV345

- Generated the Certificate with GoDaddy (copy/paste CSR into their platform)

- Generated Signed Cert and Downloaded the Zip file that had 3 files:

1. xxxxxxxxx.crt

2. xxxxxxxxx.pem

3.gd_bundle.crt

Attempted a host of ways to upload these and had to rekey the cert several times and finally:

- From the CSR record that was in the Certificate page after generating and downloading the CSR,

I clicked the "Import" button on that line,

Named and uploaded the XXXXXXXX.crt file and the record now shows:

CERTNAME | Type: Local Certificate | Signed by: Godaddy etc

- Once this was done, jumped on a network outside and was able SSL VPN in via Anyconnect

(also had to setup a subomain on Cloudflare to point to the DYNDNS FQDN for this RV so the GD Certificate would validate off our corporate domain name and we could point anyconnect to vpn.corpdomain.com and resolve the ddns FQDN - Fun!)

- After I tested the VPN I then also uploaded the "gd_bundle.crt" and that shows in the cert list as:

CERTNAME_CA | Type: CA Certificat | Signed by Godaddy etc.

(UNCLEAR IF WE NEEDED TO UPLOAD THAT BUNDLE.CRT File and kind of scratching my head why the primary cert is listed as "local" as opposed to "CA" but everything is functioning so can look into that config in detail later)

Bottom Line here - We have migrated off the "Default - Self Signed" cert of the Router.

C. Changed the SSLVPN config to use the "CERTNAME | Type: Local Certificate | Signed by: Godaddy etc" from the drop down, applied, saved and rebooted.

Aside from the above, this device is in the US and behind a Spectrum (Charter) Cable Modem, we physically swapped the Cable Modem with Spectrum expecting that would give us a new Dynamic Public IP Address (There support told us weeks ago this would work - of course it did not) so when we realized we were not pulling a new DHCP Pulic addy decided to swap WAN ports on the RV and as we guessed the WAN2 MAC address pulled a lease on a new Public IP address and we will run on that for >72 Hours and then migrate back to WAN1 and see if the Public IP addy lease has released that address.  Why am I sharing this? We ran a packet capture and saw a ton of strange traffic hitting the WAN and thought perhaps that public IP address was getting targeted for DDOS/SYN Flood attack traffic which may be what was causing our WAN to drop and clients behind the RV to lose interwebs a few times a day.

Going to let the above soak in for a few days and monitor the traffic, if we see similar wan drops in the next 24 hours we will change our DDNS name as well (in case that is/was the target not the Carrier Public IP).

Will let you know how we make out in the next week or so.

On the SSL Certificiate process I outlined above, does that look correct config wise to you?

Not a lot of clear documentation out there on applying a Godaddy SSL Certificate to the RV series router (read AG and bunches of tech notes on Cisco's site) - I am still confused and wondering if that is properly applied.

Also to wrap up - we looked at all DDNS configs/settings and all seems to be correct (both on the RV345 and in the DDNS account)

We had pointed to a Kiwi SysLog server but we were getting all the same logging as we see in the native RV logging.  Is there another syslog server product we should try?

[nagrajk1969]

Hi

>>>On the SSL Certificiate process I outlined above, does that look correct config wise to you?
>>>Not a lot of clear documentation out there on applying a Godaddy SSL Certificate to the RV series router (read AG and bunches of tech notes on Cisco's site) - I >>>am still confused and wondering if that is properly applied.

You mentioned that you had applied the below steps/procedures:

>>>Generated the Certificate with GoDaddy (copy/paste CSR into their platform)

>>>- Generated Signed Cert and Downloaded the Zip file that had 3 files:

>>>1. xxxxxxxxx.crt

>>>2. xxxxxxxxx.pem

>>>3.gd_bundle.crt

>>>CERTNAME_CA | Type: CA Certificat | Signed by Godaddy etc.

>>>(UNCLEAR IF WE NEEDED TO UPLOAD THAT BUNDLE.CRT File and kind of scratching my head why the primary cert is listed as "local" as opposed to "CA" but everything is >>>functioning so can look into that config in detail later)

1. Ok, the very first step i suggest you do is to transfer/copy all of the above 3 cert/files to a Linux-Host (say ubuntu)

2. Now, iam sure you are already aware of it, but i will mention it here again so that we can follow the logical-flow in this discussion

- In your case, the file "xxxxxx.pem" or the "xxxxx.crt" is the "signed-device-cert" (which is tagged as "Local Cert" after its imported into RV-router)

b) Now on the Linux-host, run the below command to see the contents of your "signed-certificate"

openssl x509 -in xxxxx.pem -noout -issuer

root@host#openssl x509 -in xxxxxx.pem -noout -subject
subject= /C=US/ST=NY/L=NYC/O=Cisco Systems/OU=HR/CN=rv345.xxxx.com

root@host#openssl x509 -in xxxxxx.pem -noout -issuer
issuer= /C=US/ST=NY/L=NYC/O=Godaddy Systems/OU=Main/CN=IntermediateCA1

- Now checkout with same commands above with xxxxx.crt file, just to make sure that both the xxxx.pem & xxxx.crt are one and the same

c) Next on the linux host, do a "cat gd_bundle.crt", and if iam right, you will see the contents as below:

-----BEGIN-----
sjhjhjhg
kjdkjkdkfdkfdkfdksfjd
kfhdjfhdsjfdsjfdjfsdjfdjfdjfjdshf
...and so on....
-----END-----
-----BEGIN-----
sfhjfhjfh45ttfgfg45y54regfjdshfjsdhf4u5t5tuvbjkf
jbdshjfgew091277283636452786437463
38238434mdskdjkdjf
....and-so-on
-----END-----

....and so on of the BEGIN-END blocks if there are more than 2

Now here the bundle.crt is a bundle of the CA-certs chain that contains the Intermediate-CA1 that has signed your CSR and generated the signed-cert xxxxx.crt/xxxxx.pem, AND it also has the main-top-level "ROOT-CA" that has signed the "Intermediate-CA1"..
- basically its a Chained-CA certs file

d) i suggest that you select and copy-paste each of the "Begin-End" blocks separately into separate files and name them as CA1.pem, CA2.pem...etc

NOTE: Ensure that when you copy 1 block of BEGIN to END, you also copy all the the hyphens("-") exactly as available in the output of cat command. This is important. You cannot miss even 1 hyphen OR add any extra hyphen (i think its generally 5 hyphens exactly...iam not sure now at this time)

e) Now first, for CA1.pem file, run as below:

openssl x509 -in CA1.pem -noout -subject
openssl x509 -in CA1.pem -noout -issuer

- if this was the CA-cert that had signed your CSR/local-cert, then the subject and issuer names will NOT BE SAME.
- If the issuer and subject are NOT same, then it means this is a Intermediate-CA1 certificate

f) Next with CA2.pem file, do the same steps as below:

openssl x509 -in CA2.pem -noout -subject
openssl x509 -in CA2.pem -noout -issuer

- now here if this certificate had signed the CA1.pem, then the subject-name of this CA2 cert will be the same as "issuer-name" in CA1.pem file
- And if this is the main top-level-CA cert, then both subject and issuer names of this CA2.pem will be the same

g) So now what you need to do is to check/compare whether in the gd_bundle.crt file, the "Begin-End" data-blocks (for CA1.pem and CA2.pem respectively) are as in below order or not:

root# cat gd_bundle.crt

<the begin and end block of CA1.pem intermediate-CA file>
<next the begin and end block of CA2.pem the main-root-CA file>

- the order MUST be as above
- else you need to create a new file and paste the begin-end blocks in the above order, and save it as a separate gd-bundle2.crt

Note: The general order of the "Begin-End" blocks in a bundled-CA-cert file will be as below (depending on how many levels of intermediate-CA are there)

<intermediate-CA1 that has actually signed the device-CSR-cert>
<the next level Intermediate-CA2 that has signed CA1 above>
<the next level Intermediate-CA3 that has signed CA3 above>
....
<the last main top-level ROOT-CA-cert>

3. So once you have confirmed/checked that the gd_bundle.crt is in correct order, OR if not, you have created another bundle2.crt file in correct order, you should import this correct bundle-CA cert file in to the RV-router

NOTE: The bundled-CA certs are NOT supported in the IPsec VPN tunnels (S2S and/or C2S) when imported as bundle-CA-cert. As mentioned above, you have to create those CA1.pem, CA2.pem, etc and import them separately into RV to use in IPsec-VPN tunnels (S2S and/or C2S).

- you can import the bundle-CA file as is and then you can also import again the individual CA1/CA2/etc certs and only then use them in the ipsec-vpn tunnel configs...

hope the above info helps...

[Douglas Byrne]

Nagrajk - firstly thanks for all the suggestions you provided here. Greatly appreciate the support of this community.

Quick Update - appears the issues of losing internet connectivity to all devices connected to the RV345 intermittently has been resolved.  Despite all of the configuration changes we made, at this point, we believe the issue was being caused by malicious traffic pointed at the router.

Through this process we decided to swap the Spectrum Cable Modem provided by the carrier.  In doing so we were hoping to get a new public IP address in the process as well as this is a dynamic IP for this site.  Got the new cable modem, swapped it out, connected to RV345 and still got the previous Public IP address.  They had suggested if we wanted a new IP we would need to disconnect for 72 hours and hope that someone else grabbed that IP.  Thought about that for a minute and decided a 72+hour downtime was not going to work.  Gave it a bit more thought then had the idea to terminate the Cable modem into the 2nd WAN port of the RV345 (guessing the pub IP addy was leased to the MAC addy of the WAN Port) and voila! Got a new Public IP address.

Since making that change, all issues we were having resolved, no more SSL VPN attempt errors and no loss of internet connectivity to all devices connected to the RV and DDNS error message.  Not sure what was going on as we did have all DDOS protection and otherwise configured on the device.

We have also recently upgraded the firmware to the latest release 1.0.03.24 and all is running fine with the exception of a once daily error of:

2021-11-20T02:42:59-05:00 <error>dnsmasq: failed to parse lease database cleanly
2021-11-20T02:42:59-05:00 <error>dnsmasq: failed to allocate -1 bytes

We these RV345's at 2 sites and both kick off the above dnsmasq error once daily but this does not appear to impact operation at all.

Again, thanks for the suggestions along the way.