Caldav not working from FQDN but works from IP address

ℹ️ Support
1

I just rebuilt my Nextcloud server using Debian, PHP7, MariaDB, and Nginx. Everything is working perfectly with the web UI. I use Thunderbird with Caldav on my desktops and that is working fine so I know that caldav is working on the server. BUT I use Davdroid on my Android phone and tablets and I can not get the app to work. It was working before the rebuild.

The Davdroid app fails when creating the caldav account. There are no errors in the Nginx or PHP log files. Here’s some info that might help though:

I use https for Nextcloud. The server is bound to port 443 like normal but since I’m doing port forwarding through my router the URL is something like https://server.blah.com:6767. When traffic hits my router for that url, it is forwarded to a local LAN IP, let’s say 192.168.1.20 on port 443. It has worked fine like this for the year I’ve been running Owncloud/Nextcloud and it is working fine now for the web UI and Thunderbird using caldav. My trusted hosts line in the config.php has '0 => ‘server.blah.com:5556’. So just for fun, I added my server’s IP address into the trusted hosts section as '1=> ‘192.168.1.20’. With that entry and using “https://192.168.1.20/remote.php/dav/” as the server URL, Davdroid can connect to the caldav services without a problem. I realize that your first instinct is to say, “This is a problem with your port forwarding, DHS, etc” but that is not the case. Like I said, I’ve been running Own/Nextcloud for a year setup exactly this way with no issues. The difference is that I am now using Nginx instead of Apache. Thunderbird can connect to caldav on my new server using “https://server.blah.com:6767/remote.php/dav/calendars/brian/recurring/” without a problem. I think that the difference between Thunderbird and Davdroid is that Thunderbird uses the entire URL to get to the caldav calendar (ie https://server.blah.com:6767/remote.php/dav/calendars/brian/recurring/) whereas Davdroid is relying on a Propfind using the shortened URL (ie https://server.blah.com:6767/remote/dav/). But if I use “https://192.168.1.20/remote.php/dav/” with Davdroid, it works. So I believe that it is some kind of configuration problem with Nginx that is stopping caldav services from being found if using the FQDN, port number, and relying on propfind to see what caldav services are available.

Any ideas?

TIA.
Brian

2

Can you check the server logfile? There you might be able to see what davdroid is looking for and not finding. Could be the .well-known stuff …

3

So here are the Nginx access log files after Davdroid tries to connect. Not seeing anything out of the ordinary but then again, I’m a newbie to this. Any other logs I can look at?

192.168.1.1 - bongo [01/Jan/2017:09:55:27 -0500] “PROPFIND /remote.php/dav/ HTTP/1.1” 207 854 “-” "DAVdroid/1.3.5-gplay (2016/12/23; dav4android; okhttp3) Android/7.0"
192.168.1.1 - bongo [01/Jan/2017:09:55:58 -0500] “OPTIONS /remote.php/dav/principals/users/bongo/ HTTP/1.1” 200 0 “-” "DAVdroid/1.3.5-gplay (2016/12/23; dav4android; okhttp3) Android/7.0"
192.168.1.1 - bongo [01/Jan/2017:09:55:58 -0500] “PROPFIND /remote.php/dav/ HTTP/1.1” 207 1658 “-” "DAVdroid/1.3.5-gplay (2016/12/23; dav4android; okhttp3) Android/7.0"
192.168.1.1 - bongo [01/Jan/2017:09:55:59 -0500] “OPTIONS /remote.php/dav/principals/users/bongo/ HTTP/1.1” 200 0 “-” "DAVdroid/1.3.5-gplay (2016/12/23; dav4android; okhttp3) Android/7.0"
192.168.1.1 - bongo [01/Jan/2017:09:56:00 -0500] “PROPFIND /remote.php/dav/principals/users/bongo/ HTTP/1.1” 207 630 “-” "DAVdroid/1.3.5-gplay (2016/12/23; dav4android; okhttp3) Android/7.0"
192.168.1.1 - bongo [01/Jan/2017:09:56:30 -0500] “PROPFIND /remote.php/dav/ HTTP/1.1” 207 854 “-” "DAVdroid/1.3.5-gplay (2016/12/23; dav4android; okhttp3) Android/7.0"
192.168.1.1 - bongo [01/Jan/2017:09:57:01 -0500] “OPTIONS /remote.php/dav/principals/users/bongo/ HTTP/1.1” 200 0 “-” "DAVdroid/1.3.5-gplay (2016/12/23; dav4android; okhttp3) Android/7.0"
192.168.1.1 - bongo [01/Jan/2017:09:57:02 -0500] “PROPFIND /remote.php/dav/ HTTP/1.1” 207 1658 “-” "DAVdroid/1.3.5-gplay (2016/12/23; dav4android; okhttp3) Android/7.0"
192.168.1.1 - bongo [01/Jan/2017:09:57:03 -0500] “OPTIONS /remote.php/dav/principals/users/bongo/ HTTP/1.1” 200 0 “-” "DAVdroid/1.3.5-gplay (2016/12/23; dav4android; okhttp3) Android/7.0"
192.168.1.1 - bongo [01/Jan/2017:09:57:04 -0500] “PROPFIND /remote.php/dav/principals/users/bongo/ HTTP/1.1” 207 630 “-” “DAVdroid/1.3.5-gplay (2016/12/23; dav4android; okhttp3) Android/7.0”

4

Another update. If I use the full URL https://server.blah.com:6767 on my LAN, Davdroid fails. If I turn off wifi and use my mobile carrier’s Internet, Davdroid works. It looks like Nginx is having issues with returning data to addresses on the LAN using the FQDN and port number. As you can see in the access log post above, it sees the request coming from the LAN address of my router. When I connected via mobile internet, it logged the IP address of my phone.

172.58.55.234 - bongo [01/Jan/2017:10:13:18 -0500] “PROPFIND /remote.php/dav/ HTTP/1.1” 207 854 “-” “DAVdroid/1.3.5-gplay (2016/12/23; dav4android; okhttp3) Android/7.0”

When I was running Nextcloud with Apache, I did not have this issue. Davdroid worked on my LAN or from the Internet using the FQDN. So there must be a setting in Nginx that is misconfigured but I don’t know enough about it to find the problem. Any ideas?

Brian

PS I have the following well-known entries in my Nextcloud Nginx config file as specified in the NC documentation.

location = /.well-known/carddav {
return 301 $scheme://$host/remote.php/dav;
}
location = /.well-known/caldav {
return 301 $scheme://$host/remote.php/dav;
}

5

Here is a post that I posted on the Nginx mailing list that summarizes the situation nicely. Maybe it will help you help me. :wink:

Greetings everyone! Happy New Year. I am a new Nginx user with a curious problem that I can not seem to fix. Here is my environment.

(URLs and IPs have been changed to protect the innocent) :wink:

I have a Debian/Nginx/MariaDB/PHP7/Nextcloud server running on my LAN on IP 192.168.1.20. I’m running https and the server is up and running properly. I can connect my secure Nextcloud website without a problem from my LAN. From the Internet, I have a registered URL that points at the WAN port of my router: server.blah.com.

On the router, I have forwarded port 6767 to port 443 on my server. I can connect to the Nextcloud website on the server from both the LAN and Internet using the URL https://server.blah.com:6767. So far so good, right?

Here is the problem. I use the caldav features of the Nextcloud server to sync calendar and contact data to my phone. I use the Davdroid client to connect to the caldav features of the server. The URL that is used to connect to the server for caldav discovery is:

https://server.blah.com:6767/remote.php/dav/.

Following the instructions from Nextcloud, I have two entries in my Nginx config file addressing caldav:

location = /.well-known/carddav {
return 301 $scheme://$host/remote.php/dav;
}
location = /.well-known/caldav {
return 301 $scheme://$host/remote.php/dav;
}

When I try to connect Davdroid to the Nextcloud website from my LAN using the URL ( https://server.blah.com:6767/remote.php/dav/), it fails. Here is the access log entries when I try to connect: (There are no entries in the error log.)

192.168.1.1 - bongo [01/Jan/2017:09:55:27 -0500] “PROPFIND /remote.php/dav/ HTTP/1.1” 207 854 “-” "DAVdroid/1.3.5-gplay (2016/12/23; dav4android; okhttp3) Android/7.0"
192.168.1.1 - bongo [01/Jan/2017:09:55:58 -0500] “OPTIONS /remote.php/dav/principals/users/bongo/ HTTP/1.1” 200 0 “-” “DAVdroid/1.3.5-gplay (2016/12/23; dav4android; okhttp3) Android/7.0”

BUT when I connect Davdroid to the Nextcloud website from the Internet, it works properly. Here are the access logs from when it works properly:

172.58.84.223 - bongo [01/Jan/2017:10:13:18 -0500] “PROPFIND /remote.php/dav/ HTTP/1.1” 207 854 “-” "DAVdroid/1.3.5-gplay (2016/12/23; dav4android; okhttp3) Android/7.0"
172.58.84.223 - bongo [01/Jan/2017:10:13:18 -0500] “OPTIONS /remote.php/dav/principals/users/bongo/ HTTP/1.1” 200 0 “-” "DAVdroid/1.3.5-gplay (2016/12/23; dav4android; okhttp3) Android/7.0"
172.58.84.223 - bongo [01/Jan/2017:10:13:19 -0500] “PROPFIND /remote.php/dav/ HTTP/1.1” 207 1658 “-” "DAVdroid/1.3.5-gplay (2016/12/23; dav4android; okhttp3) Android/7.0"
172.58.84.223 - bongo [01/Jan/2017:10:13:20 -0500] “OPTIONS /remote.php/dav/principals/users/bongo/ HTTP/1.1” 200 0 “-” "DAVdroid/1.3.5-gplay (2016/12/23; dav4android; okhttp3) Android/7.0"
172.58.84.223 - bongo [01/Jan/2017:10:13:20 -0500] “PROPFIND /remote.php/dav/principals/users/bongo/ HTTP/1.1” 207 630 “-” "DAVdroid/1.3.5-gplay (2016/12/23; dav4android; okhttp3) Android/7.0"
172.58.84.223 - bongo [01/Jan/2017:10:13:27 -0500] “PROPFIND /remote.php/dav/principals/users/bongo/ HTTP/1.1” 207 738 “-” "DAVdroid/1.3.5-gplay (2016/12/23; dav4android; okhttp3) Android/7.0"
172.58.84.223 - bongo [01/Jan/2017:10:13:27 -0500] “PROPFIND /remote.php/dav/principals/users/bongo/ HTTP/1.1” 207 790 “-” "DAVdroid/1.3.5-gplay (2016/12/23; dav4android; okhttp3) Android/7.0"
172.58.84.223 - bongo [01/Jan/2017:10:13:27 -0500] “PROPFIND /remote.php/dav/principals/groups/admin/ HTTP/1.1” 207 652 “-” "DAVdroid/1.3.5-gplay (2016/12/23; dav4android; okhttp3) Android/7.0"
172.58.84.223 - bongo [01/Jan/2017:10:13:27 -0500] “PROPFIND /remote.php/dav/principals/groups/admin/ HTTP/1.1” 207 723 “-” "DAVdroid/1.3.5-gplay (2016/12/23; dav4android; okhttp3) Android/7.0"
172.58.84.223 - bongo [01/Jan/2017:10:13:28 -0500] “PROPFIND /remote.php/dav/addressbooks/users/bongo/ HTTP/1.1” 207 3220 “-” "DAVdroid/1.3.5-gplay (2016/12/23; dav4android; okhttp3) Android/7.0"
172.58.84.223 - bongo [01/Jan/2017:10:13:28 -0500] “PROPFIND /remote.php/dav/calendars/bongo/ HTTP/1.1” 207 14245 “-” "DAVdroid/1.3.5-gplay (2016/12/23; dav4android; okhttp3) Android/7.0"
172.58.84.223 - bongo [01/Jan/2017:10:13:28 -0500] “PROPFIND /remote.php/dav/addressbooks/groups/admin/ HTTP/1.1” 404 11837 “-” “DAVdroid/1.3.5-gplay (2016/12/23; dav4android; okhttp3) Android/7.0”

So I’m sure you are asking “Are caldav services working at all?” I can answer with a resounding “Yes!” How do I know? Well, I am using the Thunderbird email client on my LAN and connect to the caldav services for calendar sync and caldav is working fine. But here is another clue that might help. While Davdroid uses this URL to connect:

https://server.blah.com:6767/remote.php/dav/

and then uses propfind to see available services, Thunderbird uses this URL to get to directly to specific calendars:

https://server.blah.com:6767/remote.php/dav/calendars/bongo/recurring/

where “recurring” is the calendar name. Here is an example access log entry where Thunderbird connects successfully to sync via caldav:

192.168.1.1 - - [01/Jan/2017:10:31:30 -0500] “PROPFIND /remote.php/dav/calendars/bongo/main/ HTTP/1.1” 401 567 “-” "Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 Lightning/4.7.4"
192.168.1.1 - - [01/Jan/2017:10:31:30 -0500] “PROPFIND /remote.php/dav/calendars/bongo/birthdays/ HTTP/1.1” 401 567 “-” "Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 Lightning/4.7.4
192.168.1.1 - bongo [01/Jan/2017:10:31:59 -0500] “PROPFIND /remote.php/dav/calendars/bongo/main/ HTTP/1.1” 499 0 “-” "Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 Lightning/4.7.4"
192.168.1.1 - bongo [01/Jan/2017:10:31:59 -0500] “PROPFIND /remote.phate to say it, but when I ran the same exact setup but with Apachep/dav/calendars/bongo/birthdays/ HTTP/1.1” 499 0 “-” “Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 Lightning/4.7.4”

I really think that this has something to do with the caldav directives in the Nginx config file since using

https://server.blah.com:6767/remote.php/dav/calendars/bongo/recurring/

works on my LAN but

https://server.blah.com:6767/remote.php/dav/

does not. I tried removing the caldav directives and restarting Nginx, but it did not fix the problem. I hate to say it, but when I ran the same exact setup but with Apache, caldav worked fine regardless of LAN, WAN, or client. I just rebuilt the server this week and decided to use Nginex this time since it is faster. It is indeed faster than Apache but if I can not get this problem fixed, I will have to go back to Apache. Please help me avoid that! :wink:

Brian

1 Like