3

I would like to host a CalDAV and CardDAV server for devices that will roam between being on the LAN to outside my network (such as my iPhone and laptops). A static IP is prohibitively expensive.

I have a my own domain, a Mac Mini with Lion Server, a SonicWall TZ 200 and a dyn.com dynamic address (the SonicWall keeps the dynamic account updated). I would normally set up a static IP and use split horizon DNS so those roaming devices can point to server.mydomain.com and function on and off my LAN.

Is a similar setup possible with the dynamic address? I am happy to set up the clients with either server.mydomain.com or myaccount.dyndns.org but I would prefer to use my domain.

Would either hairpin NAT on the SonicWall or split horizon DNS using the Lion Server allow this to work?

ridogi
  • 214
  • 2
  • 7

1 Answers1

2

The reason split horizon DNS is set up is almost always because an internal service cannot be reached off of the LAN. For example, Active Directory domain controllers that also hold internal DNS. If your all of your services are intended to be externally reachable then split DNS isn't necessary, strictly speaking. Discard any use of split DNS in your design until you find a sure reason to use it.

Hairpin NAT / tromboning would be how anyone behind your firewall would reach your server, which is acceptable. The biggest downside to hairpinning is that it "unnecessarily" engages your SPI engine and anything else running in the firewall like UTM services. However, if that's how you intentionally designed it, then it's hard to call it "unnecessary" - the TZ 200 can take a decent amount of traffic and I highly doubt a CalDAV/CardDAV service will be getting thousands of requests per second from your internal network. =)

Wesley
  • 32,320
  • 9
  • 80
  • 116
  • I've set up hairpin NAT like this http://www.fuzeqna.com/sonicwallkb/consumer/kbdetail.asp?kbid=8612&formaction=faqalert which works for the standard port, but I can't connect on the SSL port 8443. If I enter a local IP and select SSL I can connect so the problem must be in the server name and/or cert which is self signed, and not as dyndns.org of course. – ridogi Apr 21 '12 at 04:26