Solved Access via CalDav works internally, but not w/external hostname.

[Mortify]

Those tests didn't show anything consistent. The fact that my Mac only connects to the IP via SSL (5001 works too) and the other Mac only connects without it is a total mystery.

It's an Asus RT-AC66U. There is a NAT loopback dropdown under the Firewall which lets me select "Asus" or "Merlin". I tried both settings and attempted to connect via DDNS address on all 4 ports, but no change. The router firewall was off before this test, on for the test, and is off again.

 

[Mortify]

I am starting to suspect a certificate issue. I deleted and recreated the DDNS certificate on the NAS to be sure, and there's no change.

 

[Rusty]

I have to seep on this a bit. Not sure what the problem is here. Must be something stupid and small...

 

[abramq]

In my situation (getting CalDav, Moments, DSFile,...) from local network using xxx.synology.me address I have found other solution. My router couldn't resolve this address, so I've installed on Synology packet "DNS server", added path to resolve my address, then modified WiFi settings on my mobile devices to "Static" IP and pointed my new DNS server. A little complicated, but with simple routers - the only possible as I've found.
P.S.
On PCs I just added a line into Windows's hosts file. Actually, you can do the same with mobiles, if you have root there.

 

[Mortify]

Something stupid seems apropos, so I did the only thing that makes sense: uninstall Synology Calendar and delete the database. Then I reinstalled, created one calendar, connected all devices, and verified that connectivity was maintained as I made changes.

The great news:
The calendars are syncing on both laptops and my phone via SSL with the DDNS address. Goal achieved! Well, there are more devices to configure, but this looks promising.

The weird news:
They sync only on port 5001. 38443 and 38008 don't work regardless of the config. Syncing via port 5000 without SSL also doesn't work.

 

[Rusty]

In my situation (getting CalDav, Moments, DSFile,...) from local network using xxx.synology.me address I have found other solution. My router couldn't resolve this address, so I've installed on Synology packet "DNS server", added path to resolve my address, then modified WiFi settings on my mobile devices to "Static" IP and pointed my new DNS server. A little complicated, but with simple routers - the only possible as I've found.
P.S.
On PCs I just added a line into Windows's hosts file. Actually, you can do the same with mobiles, if you have root there.

And this is absolutely correct if you do not have a nat loopback support, but Mortify, does.

 

[Rusty]

Goal achieved!

Great news. But not sure what else you could do here. Looks like there was a problem with Calendar DB of some sort.

 

[fredbert]

Mucking about with this and the new Contacts beta I've found that sometimes the Application Portal app direct domains don't always get created correctly. I've recreated the Contacts direct domain again and 'contacts.mydomain.com' now works to port 443 where before it didn't, and so too does 'calendar.mydomain.com'.

 

[Rusty]

Could be a built-in nginx problem

 

[Gerard]

Thank you for taking the time to walk through this and showing that it works. After following these examples, I'm still having the problem (and going slightly crazy). The only difference being the reverse proxy as I have the ports forwarded. See examples below:

First, I confirmed that both ports are open.
View attachment 790
View attachment 791
Below are the port-forwarding rules in the router. Note that notestation ports are forwarded and that they work using the DDNS domain name on both an external network and locally with the same account that is failing for Calendar.

View attachment 794

Then, I checked to see what was in the Firewall. There were no entries, so I created an allow rule for Calendar.
View attachment 792

Then I tried connecting via Apple Calendar
View attachment 793

All that I need to do to make this work is change the server address to the server's local IP. I feel like I'm going crazy. This seems like a port-forwarding or firewall issue, but we've validated that the ports are forwarded and the firewall allow rules are in place (I even tried it with the firewall disabled). At this point, I'd love to trace what happens when I try connecting from Apple Calendar to determine where the request is being dropped, but I don't know how.

One difference that I see is on this screen, you have that 38443 port number, yet rustys example had 443?

 

[Rusty]

Ok this has gone long enough. Just got some time and went to test it out.

Using a custom domain (on top of ddns.synology.me name) I have installed calendar and revers proxied it to 443/https (considering that that port is open for me).

Upon installing the app, Syno firewall added these 2 ports:

View attachment 780

I did not port forward these ports at all.

After configuring the Calendar app to work via https://calendar.mydomain.something I have used these Advanced settings in Apple Cal app:

View attachment 781
IMPORTANT!
Notice the trailing "/" after the username in the Server Path parameter. Thats not there by default and it needs to be. Authentification worked in a matter of seconds (in LAN and WAN scenarios).

View attachment 782

Just wanted to say that after a while I have started to have the need for a self-hosted cal and started to set this up. In the end, I was not able to connect via macOS cal.

Turned out I forgot to map SSL cert to my RP entry. That solved it. Just wanted to share in case someone also missed this and the lack of macOS info on the error might lead to some headache.