Currently Being ModeratedApr 26, 2011 12:17 PM (in response to Sven-Goran Ljungholm1)
Thanks for the help Sven,
Adding the port number does not work sadly. It does not help that I do not have access personally to the firewall. Its an unusual setup and the ISP is opening up ports at my request so its a bit long-winded going back and forth opening up new ones all the time. All my other services are working fine however and they have triple checked that 8443 is open.
I have tried using 8843 instead which is open and working for the Address Book server but it does not help with iCal.
The ISP said they could see my IP address trying to connect via 443 when I last tried to access the iCal server but even opening 443 as well does not fix the issue. iCal consistently claims there are no CalDAV servers at the specified address. Makes me wonder if it needs a public SRV record, though there isn't one for the internal DNS.
Currently Being ModeratedApr 26, 2011 1:13 PM (in response to Waragainstsleep)
You should have 8008 and 8443 both open on the firewall, first off. I'm assuming you're not using the NAT and Firewall services in OS X since you're connected to a firewall.
If both ports ARE indeed open, I suggest that you verify that the certificate is properly installed on the iphone or device that's trying to connect.
If it is, and you're sure that all the settings are right on the remote device, then the server is probably to blame.
I'd start my trouble shooting by seeing if the server will work when NOT using a secure method.
In Server Admin, select iCal. Select Settings and click the Authentication button.
Under "SSL" choose Don't Use.
Save your settings. If it doesn't ask you to restart the iCal service, you should do so. (most likely it will)
Now, on your remote devices, create a new Calendar connection to the server that doesn't use SSL.
If it connects, it's a firewall problem. (again, assuming your certificate is valid)
If it doesn't connect, it's most likely a remote device problem.
Currently Being ModeratedMay 3, 2011 12:48 PM (in response to Waragainstsleep)
I am seeing similar issues. Currently I have the following set up:
Internet--pfSense router--OPT1.209--1:1nat--LAN.209--mac mini ical server.
I have a split dns set up to help with nat reflection issues. when i do nslookup with the mac I see that
LAN.209 <--> server.mydomain.com works resolves both ways. From a computer positioned out side the lan i see that the nslookup WAN.209 <--> server.mydomain.com. The iCal service works on the LAN subnet. That is the easy part. When I try to probe port 8443 or 8008 from a remote location the ports hang and never respond. The firewall is currently completely disabled and I can access other services such as ssh remotely using the servers dns name. I figured that this could be some issue with dns because I know that dns and ical are closely related, so I changed the dns server of the ical server to googles public dns server and attempted to connect remotely... again nothing. This appears to have no effect on the LAN functionality as well. There must be something Im missing but I would love to be able to update my iCal's from anywhere on the internet.
P.S. Im willing to provided any other details that might be needed to resolve this issue.
Currently Being ModeratedMay 3, 2011 1:09 PM (in response to Waragainstsleep)
So I have an update that might be helpful. After doing some tcpdumping I found that the request are not coming in on port 8443 but port 443. I opened up server admin and changed the port to 443 for the iCal service and now its working on the internet. I would love to know why this behavior is happening and Im wondering what would happen if i was running https on this server?
Currently Being ModeratedMay 4, 2011 4:05 AM (in response to booginga)
So port 443 works for me too but I know that my client plans to add web services in the future so like Boog, I'm not sure this is a permanent solution.
I can confirm however that it is not necessary to open 8008 which is good because I really only want secure data coming in and out of the LAN.
During the course of my previous setup and troubleshooting, I had various ports opened for ARD, Address Book sharing, Mail etc, and they all worked just fine. When port scanning however port 8443 was one which never showed as open, though some others didn't show either and still worked regardless.
Currently Being ModeratedMay 23, 2011 3:02 AM (in response to Waragainstsleep)
Right so this is weird. I got frustrated and installed a demo of Kerio Connect. I love Kerio but I was hoping I wouldn't need to buy a copy. As soon as I installed it however, the 'missing' ports started to show on port scans and even after I turned Kerio off and went back to the built in SL services everything continues to work inside and out and has done for over a week now.
I'd love to know what Kerio did to 'force' those ports open but its working so there you go. I only used the trial version so if anyone else is having this issue, it might be a good quick fix for you.
Thanks to all who contributed.
Also, Sven, I had no access to the router to put the server in the DMZ. I could have asked the ISP but then I would have had to have them remove it again later and there is always a lag on these requests.
Currently Being ModeratedMar 15, 2012 5:21 AM (in response to booginga)
I was having a similar issue with iCal Server. I had Address Book Server and iCal Server working just fine and using SSL without the Firewall activated in Server Admin. I then proceeded activate the firewall, opening up ports 8008 & 8443 (iCal Server) and 8800 & 8843 (Address Book Server). This killed connectivity to iCal Server, but left Address Book Server untouched.
I went through several iterations of turning the firewall on & off, confirming that the client was being stopped by the firewall only.
The solution was to enable port 443 (https) in addition to the ports listed above. Now iCal Server is responsive through the firewall.