OBTAINING LETS ENCRYPT SSL CERTIFICATE WITH PEPLINK MAX TRANSIT CAT-18 - SUSCPECT CGNAT ISSUE AS THE CULPRIT

Please be patient with me. This may be a little long winded, but, the history of this has an impact.
Several years ago my son & I installed Synology NAS devices in our stick & bricks home to facilitate offsite backup as well as using the devices as a WebDav server. In order to map specific folders on the NAS to a drive on a given PC, we use the WebDrive application. At the time we were both using TW cable internet which is now Spectrum. Setup was relatively straight forward & we secured Lets Encrypt SSL certificates as outlined on the Synology application with out incident.
Fast forward to May, 2020. I have become a full time RV’er & installed a Max Transit CAT-18 for my internet connectivity. The mapping of folders on the NAS devices to a drive on a given still functions, however, my scheduled NAS to NAS backups are failing.
Coincidentally, the CISCO router at my son’s home office failed at that time & it was replaced with a Balance One Core. A PepVPN Speed Fusion one to one connection was established with the help of a member of this forum. The backups continue without issue.
Sometime late last year, Synology released a more secure version of their Disk Management System (DSM). Not a practicing early adopter of anything new, improved & more secure, the update was not applied until last week. While the DSM update went rather smoothly at my son’s location with a cable internet service provider, the WebDav server & WebDrive client application to my NAS failed.
Working with both Synology & WebDrive support, it appears that I no longer have a valid SSL certificate for my NAS. Tech support at Synology at least understands the issues with CGNAT & tell me they are looking for a work around.
Attempts to obtain a new SSL certificate via Let Encrypt times out indicating ports are messed up, check configuration, etc. etc. When I use ‘what is my IP’, it returns 174.247.7.142 which is clearly a Verizon domain. I can not successfully ping this address.
OK, here come the questions:

  1. Both the Balance One Core & the Max Transit CAT-18 are no longer covered by PrimeCare.
  2. While the PepVPN SpeedFusion tunnel continues to work, is it because I don’t need PrimeCare or has Peplink just overlooked
    that I’m using it?
  3. Can I set up additional tunnels with the PepVPN SpeedFusion, or am I limited to only one?
  4. Is there a better solution?
  5. If the solution is to activate PrimeCare, on one or both units, who do I contact as they were purchased from different
    suppliers? Will Peplink even allow this?
  6. On the surface, it seems an easy work around would be to take the NAS & my PC to a hardwired connection so Lets Encrypt can send the files that way. By the way, I tried obtaining the SSL certificate via WIFI as WAN with the RV park WIFI just to see if it might work. It did not. Is this the best solution as it’s a 2 hour round trip?
    I suspect some iteration involving a SpeedFusion license would solve the problem, but, the folks at the home office don’t deal well with any change which involves the way they do things. I’m not opposed to spending money, but,
    Please do not suggest anything involving InControl.
    Thanks in advance for any help or suggestions.

To clarify. Is the NAS with you behind the Transit now? Or elsewhere behind a Balance one core?
Assuming its behind the Balance One, if you have a PePVPN to the Balance still then you should be able to access the Synology NAS using its LAN IP from your motorhome? Can you?

Martin,
There are multiple NAS devices. 1 is behind the CAT-18, presently with Verizon as the cellular provider, and, it’s on the motor home. I am with that NAS now. This is the one giving me trouble with the SSL certificate.
The other NAS is behind a Balance One Core with cable Spectrum as the ISP provider. It is functioning as expected.
I had previously set up a PepVPN connection entitled RV to HQ to facilitate nightly backups of the NAS devices. This enable me to get around the CGNAT issue with Verizon. The scheduled backups continue to occur & are not impacted by the absence of a Lets Encrypt SSL certificate. So the short answer is the NAS behind the CAT-18 can be accessed from outside the RV.

My apologies for being so long winded. I’ve pretty much reconciled myself that obtaining a Lets Encrypt SSL certificate through the CAT-18 with cellular WAN is not going to happen. I’m looking for alternatives.
Thanks you for your response.
gk

I see and understand now.
You’ll need to make your synology nas temporarily available via port 80 and 443 from a fixed IP address for the certificate to be allocated / applied automatically.

Two ways to make this work automatically.
Redirect via a fixed IP. You could do this via the Balance one core which has a fixed public IP I think?

  1. Setup an outbound rule for your NAS to send all traffic via VPN to the balance one.
  2. Temporarily port forward from WAN of balance one to internal IP of your synology.
  3. Apply for new letsencrypt certificate

Or you could build a FusionHub and do the same thing with that.

The other way is to do the SSL request manually by sending Lets encrypt a CSR from your NAS:

Via https://gethttpsforfree.com/ which will submit the CSR to letsencrypt for you and return the cert and private key.

1 Like

There are a number of ways to do this, let us start with the easy one time way to check that the cert even fixes the problem. I’m not running DSM7, major DSM updates only happen with new hardware.

1 Have the home NAS create the certificate and use its direct IP to authorize the cert. Then you export the certificate and import it on the RV NAS.
2 As Martin indicates, you can take over the port 80 at the home for long enough to get the cert directly authorized, then put port 80 back to the home NAS.
3 Fusion Hub, or additional IP’s from the home ISP provider.

4 Synology states that the DNS-01 auth mechanism is avalable in DSM 6.3.2 and DSM7

Synology DDNS supports DNS-01 (starting with DSM 6.0) and HTTP-01 validation with Let’s Encrypt. Customized domain only supports HTTP-01 validation with Let’s Encrypt. Refer to this article for more information about validation methods.

There should really be no reason to expose your environment just to get a certificate, that method requires you to have the DNS name handled by one of the DDNS providers, I’ll give it a test later in the week. I would start with #1… See if it fixes your problem and only then try to get #4 to work.

Martin/Paul
Thank you both for the suggestions.
I’ll be the 1st to admit I muddeling my way through this Lets Encrypt SSL certificate thing.
Option 1 seems to be the easiest & less time consuming of the options at this point in time.
I am familiar with exporting the file from the NAS control panel & typically it’s downloaded to the client PC default file download location. One can then import it to the target NAS which is on the RV. I can do all this from the RV & xfer the files to the RV
How does the client PC get tied into the SSL certificate? In this case, the PC on the RV? This is the PC
with the SSL certificate issue.
Please understand, I’m not looking for an education on SSL certificates. Does the import of the certificate by the NAS take care of the PC client that is accessing the NAS in question?
Thanks in advance.

That is a question we weren’t going to cover, as you stated that Synology told you this was the solution. I am skeptical, but wasn’t going to go down that path, or it was “A solution” but perhaps not the only solution.

What cert do you have on the NAS?. It should have a CN, a SAN and start and end dates.

I can’t tell you if it will work or won’t… I don’t use that software. some explicit error messages might help.

You say you don’t want an education on SSL certificates, but yet ask a fundamental question about how the client will use the certificate. I know you want a yes or no answer, but that isn’t possible, there are too many variables.

There are two ways to trust a certificate. Either you manually tell the client to explicitly trust this particular certificate by adding it to a local trust store , You do this when you are asked to “accept the insecure connection” usually in a browser. Or the certificate must authenticate up the chain of trust via intermdiaries that are already in your trust store. Signed certificates like those from lets-encrypt (and all other public CA’s) will authenticate up the chain of trust without any other configurations on all standard clients.

I would question how this worked during the 9 or so months between when you moved your DSM 6.2 NAS to the RV… and when you updated to DSM 7. Your previous lets-encrypt signed cert would have expired (90 day lifetime) But your systems still worked. I am suspecting that you had manually imported the cert into the client and therefore it was trusted explicitly even though technically expired.

For your tests you can just import the one time cert on the NAS, and give it a try, it might work, but it will atleast get you to the point where Synology will continue debugging with you.

Paul,
I really appreciate you trying to help & apologize for my lack of knowledge.
The remark about an ‘education about SSL’ was apparently taken out of context. I fully intend upon investing the time to increase my knowledge with regards to SSL certificates. I could have expressed my intent better than I did. What I wrote did not reflect my desire, or intent, to better understand SSL certificates. Again I should have worded it better.
I’m comfortable during the initial connection to the NAS, some time ago, I had to explicitly trust the certificate. I suspect it was was created by Synology, but, I don’t know how to validate that? What ever certificate I had prior to updating to DSM7 does not appear to work now. I’m fairly confident this is a CGNAT issue with the provider.
From my perspective, a lot of us newbies are lost if a fog of acronyms when talking to more experienced users. Please take that into consideration when trying to assist us newbies. Take the following as an example:
"What cert do you have on the NAS?. It should have a CN, a SAN and start and end dates.’
I assume the question is what certificates are on the NAS? I would respond by providing the following:
image.png
I don’t know what the acronym CN, or SAN stands for. Looking at the above screen capture, I would highlight one of the certificates & look at its settings & hopefully see something indicating a
CN & a SAN along with a start & end date. Nothing there which references CN or SAN when I do that.
As part of my efforts to understand what certificates are on my client I looked in every folder available by executing ‘certmgr.msc’
image.png
My assumption being I would find a certificate from Synology or something I could identify as being from Lets Encrypt. I was not successful in identifying either. I assume this reflects my ‘trust store’.
Based on the information associated with the Syhnology DSM7 upgrade, it was to enhance security & appears to be impacted by the CGNAT issue. I have been working with Synology tech support, off & on, for a week. I get the impression they are as perplexed as I am.
Attempts to create a certificate via the previously outlined option 1 produced an error message indicating an illegal certificate when I tried to import it. I can acknowledge I could have done something incorrectly while creating the certificate from the RV.
I do thank you & appreciate the time you too to explain ‘trusting a certificate’. It was easier to understand than what I read on Lets Encrypt.
Regards,
gk

On my DSM 6.2 I can click on any of those certificates and it will tell me expanded information, including all of the names associated and which services are tied to each certificate. there is a little up/down arrow on the upper right of each cert.

What we would be interested in the the details of the Expired certificate, and what services are attached to it. (if you can expand all 3 and send another screen shot)

But I have started up my DSM 7 VM, and configured a DDNS from synology.me. You selected to have a lets-encrypt cert as part of that correct?.

Please check the top cert and that when you expand it it says “Issued by: R3”

If the webdav service is connected to cert #2 (gjknas.com) we want to move that service to the #1 cert. You click on “settings” and make sure the right cert name is selected under WebDAV.

If so you already have a lets-encrypt cert, with no port forwarding required, even with CGNAT. (Via method #4 in my first posting)

We should be able to use that cert and that name.

How do we do that?..

What do you set in the webdrive? Do you put in the gjknas.com URL? Do you put in an IP address?.

Well, what we should do is have your pepwave be the DNS server for the devices on the network.

On your peplink you go to Network->Lan Settings and Enable DNS Proxy settings.
then in the local DNS records you add gjkjrnas.synology.me with the IP address of the NAS on the local network.

You should then have sucess if you use https://gjkjrnas.synology.me:5001 or ping gjkjrnas.synology.me from clients on your private networks.

This should now allow you to configure in the webdav server, Can I assume you are using port 5006?.
https://gjkjrnas.synology.me:5006 Would be a good test in a browser. You should get no errors, no cert mismatch issues and a simple “404 not found” message.

That should then work in your client.

Paul,
Again let me express my appreciation for your help.
With regards to the Lets Encrypt certification, I suspect that goes back to the time when I was in the sticks & bricks location. When I initially started down this path & saw that the GJKNAS certificate was expired, I checked to see (in the settings) which NAS applications were attached to it. There were none. In the grand scheme of things, my ignorance related to SSL certificates is/was at play.
Here is info on 1st certificate:


Here is info on 2nd certificate

Here is info on 3rd certificate

This is the current WebDrive settings as directed by Snology to use. This is the LAN address.

I have also tried the following IP address with WebDrive.

As soon as I hit reply, I will set up the CAT-18 as the DNS server as you described above.

Paul,
While I can ping the NAS from a client & https://gjkjrnas.synology.me:5001 gets me to the sign on screen for the NAS, I am still getting the following error message with WebDrive.


In a browser going to https://gjkjrnas.synology.me:5006 I do indeed get a simple ‘404 not found’ message.
image.png

Ok… that all tells me that we have done the right things… but yet there is another issue at play. Is this the same error as before?

(that 107.77.237.137 IP will never work, that is why we had to override it at the Max Transit. That is your CGNAT address)

I’m going to try something else:

On the NAS go into Security → Advanced. and select Old Backward Compatibility.

I see nothing in the WebDrive documentation that it should have ever cared about a proper cert or name match.

If that doesn’t do it I will have to install a copy of WebDrive to test locally. The https://gjkjrnas.synology.me:5006 test, tells us that the names are right, the certs are right and you can contact the system.

Paul,
Yes this error has been consistent since I upgraded the DSM.
You may have noticed I have another NAS mapped with WebDrive & it connects with out issue. This is the one that sits behind the Balance One Core.
I could find no provision with the NAS WebDav application to specify any certificate. However I found the following in the WebDrive application:
image.png
I subsequently searched the c: drive for files with either extension. The following list was returned:
image.png
It would appear these are the client side certificates that I was wondering about. As there are 18 of them, I readily admit I have no clue which one to pick to see if it will work with WebDrive, or, if any of them are relevant.
I checked the settings on one of the clients behind the Balance One Core, none of the advanced WebDrive settings were utilized.
I applied the Old Backward Compatibility to the NAS. The following error message was returned attempting to map to the RV NAS at 192.168.50.10:5006.

No, as the system says “Some secure systems may require” Synology is not one of these systems and wouldn’t know how to handle a client cert.

Those .pfx files are just part of a standard windows install, they aren’t for your direct use.

Lets go over the matrix:

This client can connect via webdav to the other DSM7 NAS. (DSM7 right?) but not the RV.
Other clients can connect to either? is this true?. Can any other client talk to the RV NAS?.

Can you install a new copy of webdrive on a bare machine and test with that? (install in a VM if you need to)

One thing comes to mind, I was reminded by this thread that you can lock an account out by IP:

Are there any private IP addresses in the Security → Protection → Allow/Block lists. ?

there is also a log available in WebDAV (in the WebDav settings)

I will install a test Windows 10 installation, and If I see no problems with an out of the box WebDrive and DSM7 webdav then it will be something extremely specific to your environment, and we may have to get out the big guns… ssh CLI access and tcpdump.

Paul,
Probably the best way for me to respond is with notes posted under your questions. I’ve wanted to get over to the home/office & use one of the clients there to respond to some of your questions. Unfortunately we are dealing with a positive COVID test over there & the soonest I can go over is this Wednesday
Using the WebDrive application to map drives was done to maintain some consistency in the look & function of the various clients accessing the NAS devices. I never expected to encounter this ‘mess’ with the DSM upgrade. I knew some of the Synology applications would require some tweaking, but, this issue really caught me unprepared…
I can’t tell you how much I appreciate the time & effort you have put into this. Thank you!
Lets go over the matrix:
This client can connect via webdav to the other DSM7 NAS. (DSM7 right?) but not the RV.
Other clients can connect to either? is this true?. Can any other client talk to the RV NAS?.
This client (on RV) can connect via WebDav to the NAS behind the Balance One Core. That NAS was upgraded to DSM7 also. This client can not talk to the RV NAS via WebDav. All clients behind the Balance One Core can connect to the NAS via WebDav. Typically, clients behind the Balance One Core have no need to connect to the RV NAS via WebDav, so I don’t have an answer. I will see if I can accomplish a connection that way & update. We use the RV NAS to backup our working files from the NAS behind the Balance One Core using PEPVPN. That backup is scheduled to run during the night.
Can you install a new copy of webdrive on a bare machine and test with that? (install in a VM if you need to)
Hmmm! Would be a learning experience for sure. I have uninstalled & reinstalled the WebDav server application on the RV NAS. I have also uninstalled & reinstalled the WebDrive application on the RV client. Nothing changed.
One thing comes to mind, I was reminded by this thread that you can lock an account out by IP:

Hi! Come and join us at Synology Community. A place to answer all your Synology questions. Ask a question or start a discussion now.
Are there any private IP addresses in the Security → Protection → Allow/Block lists. ?
I checked the setting and there are no IP addresses blocked.
there is also a log available in WebDAV (in the WebDav settings)
While the WebDav log is enabled, there are no entries in it dated after December, 2018. I don’t understand that. That would seem to suggest I’ve not accessed the WebDav server in close to 3 years. I can not explain that.
I will install a test Windows 10 installation, and If I see no problems with an out of the box WebDrive and DSM7 webdav then it will be something extremely specific to your environment, and we may have to get out the big guns… ssh CLI access and tcpdump.

Paul,
I connected to one of the clients behind behind the Balance One Core just now.
As you can see from the screen capture below gjkjrnas.synology.me converts to IP 70.35.185.251.
I created a WebDrive mapping on that client to 70.35.185.251:5006. It failed with the same error message.


While I’ve not tried with other clients behind the Balance One Core, I suspect I will get the same results.
Have a good evening & thanks for all your help today.
gk

No,
You must either put in the DNS proxy config with the internal IP override, or just configure using the 192.168.50.10:5006 server address.

When you “ping” in your previous tests, what was the IP that came back?.

Change the server in WebDrive to https://192.168.50.10:5006 Or https://GJKJRNAS.synology.me:5006 as long as that DNS name resolves to the correct 192.168.50.10 address.

and in WebDrive under “webdav settings” → Certificate Settings → “automatically accept the server certificate” (or not, it will prompt you to accept it. )

Are you sure your other webdav settings weren’t 192.168.?.?:5005 ?

By default the system connects without TLS/SSL, and nginx will answer just enough to let us know that in a packet capture.

Once I set my client to https:// it connected, but wouldn’t map the W: drive.

For long term stability, either accept whatever cert it sends you, or have the name/IP mapping consistent and the certs will update every 90 days.

Paul,
I’m not ignoring you. I’m having to wear one of my other hats right now.
I appreciate all the help you are providing & I will respond as quickly as I possibly can.
Thanks,
gk

i was looking at certs and i don’t own the domain to my ddns provider, so i don’t think certs will work, please correct me if i am wrong. coincidently, i have a synology on the way and am internested in whats required to have the nas located at a remote site. I want to backup my server, and have a private cloud. It’s such a pain with CGNAT. Today i do have a workaround, i use a vpn provider and have the openvpn license with correct port forwarding at the router and within my vpn providers admin page. I also do this to host plex. The connection has its own DDNS with fallback servers with the correct port forwards for them as well. I tested created a local openvpn server over my existing vpn, performance wasn’t great, but it worked with a public ip/DDNS