<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 24, 2016, at 2:53 PM, Kyle Silfer <<a href="mailto:kyle@rtoads.com" class="">kyle@rtoads.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Here’s another piece of info I found out by trial and error and have been meaning to report.<br class=""><br class="">Apple's Contacts client refuses to connect on nonstandard ports (for example, it wants 8843 for SSL). You have the option to change the port number after it fails its initial connect, but it doesn't really work. Once I matched the port number, it worked fine for newer clients (although not with the OS X 10.6 Address Book).<br class=""></div></div></blockquote><div><br class=""></div><div>Depending on your server-side / DNS setup, you may have more reliable results by using the 'manual' connection setup in Contacts; the one where you specify username, password, and server, instead of email address and password.</div><div><br class=""></div><div>A CardDAV client can try multiple things when setting up an account, including looking for DNS SRV records and looking for /.well-known configuration. Both of these can help mitigate problems when using 'automatic' setup, when the server that doesn't have an IP address returned by a request for a DNS A (address) record for the email address domain. More info on these techniques can be found here: <a href="https://tools.ietf.org/html/rfc6764" class="">https://tools.ietf.org/html/rfc6764</a>. In my experience this can usually be shortcut by supplying user@servername instead of email address.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">Because calendarserver delivers both Contacts and Calendars on the same port (8443 by default), it becomes necessary to do something like redirect port 8843 to 8443 either on the host (using rinetd in Linux) or using NAT on an external device.<br class=""></div></div></blockquote><div><br class=""></div><div>For me, Contacts has no problem accessing 443, which in my case is also reverse proxied to Calendar & Contacts server.</div><div><br class=""></div><div>sudo lsof -n -l -P | grep Contacts:</div><div>Contacts 7509 501 61u IPv4 0x98ff3c379420f4ff 0t0 TCP 192.168.2.89:52097->1.2.3.4:443 (ESTABLISHED)<br class=""><br class=""></div><div>I also experimented with forcing Contacts to use other ports. If you're game, give some of this a try and report back.</div><div><br class=""></div><div>1) On the client, add two lines to the end of /etc/pf.conf to block outbound packets to the server on ports 443 and 8443:</div><div><br class=""></div><div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class="">block out quick on en0 proto tcp from any to 1.2.3.4 port 443</div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class="">block out quick on en0 proto tcp from any to 1.2.3.4 port 8443</div></div><div><br class=""></div><div>2) Load rules & enable pf if it wasn't already enabled.</div><div>sudo pfctl -Fa -f /etc/pf.conf</div><div>sudo pfctl -e</div><div><br class=""></div><div>3) double check:</div><div>╭─ andre@foci ~<br class="">╰─ $ nc -v -G 2 -z <a href="http://example.com" class="">example.com</a> 443 2>&1 | tail -n 1 <br class="">nc: connectx to <a href="http://example.com" class="">example.com</a> port 443 (tcp) failed: Operation timed out<br class="">╭─ andre@foci ~<br class="">╰─ $ nc -v -G 2 -z <a href="http://example.com" class="">example.com</a> 8443 2>&1 | tail -n 1<br class="">nc: connectx to <a href="http://example.com" class="">example.com</a> port 8443 (tcp) failed: Operation timed out<br class="">╭─ andre@foci ~<br class="">╰─ $ nc -v -G 2 -z <a href="http://example.com" class="">example.com</a> 8843 2>&1 | tail -n 1<br class="">Connection to <a href="http://example.com" class="">example.com</a> port 8843 [tcp/*] succeeded!</div><div><br class=""></div><div>4) Add Contacts account in 'manual' mode, specifying user@servername instead of email address. The client did fine by default (when the server accepted 443, 8443, 8443), and with 443 blocked. When I blocked 8443, account setup failed the first time, and worked the second time. Weird.</div><div><br class=""></div><div>5) Disable the block rules by commenting the two lines you added to /etc/pf.conf, then</div><div>sudo pfctl -Fa -f /etc/pf.conf</div><div><br class=""></div><div>-dre</div></div><br class=""></body></html>