net-plus-ultra
Level 1 (5 points)

Q: OS X Server 5.0+ > VPN Host Name

Following the recent OS X Server updates to v5.0+, I’m in the process of checking my initial server name settings, within the context of the activation of VPN service for the purpose of initial testing. My server is configured as an Intranet which will provide (native) Wiki services to (future) registered users who will connect through VPN from outside my LAN boundaries.

 

The following information is necessary to understand my questions:

1: My server’s host name: keyword.host-name.private

2: My server’s name: server-name.local

3: My server’s VPN host name, by default of 1: keyword.host-name.private

4: Observation: when I connect to my Wiki from the Server app’s Wiki service panel, my Safari browser directs me to the following default url « server-name.local », which is new (in the previous OS X Server versions, it used to connect me to the host name « keyword.host-name.private », which often caused connection failures requiring Apple Care intervention).

 

My questions:

A: Is point 4 an improvement, or a contradiction with 1? (To me, it is rather an improvement, as it confirms that I’m connecting to my own Wiki service as the machine administrator; but still, that assumption needs confirmation, as a configuration mistake at this stage would compromise all Wiki contents in case of a subsequent change of host name).

B: As the OS X Server guide confirms (please refer to: https://help.apple.com/serverapp/mac/5.0/?lang=en#/apd93635C54-9024-4056-92E9-2A 9BB3E7B3E7, point 4):

« Verify that the VPN host name resolves to the VPN server from the internet. The VPN host name shouldn’t end in “.local” or “.private.” It should be an Internet-accessible, fully-qualified domain name. »


I understand that a domain name such as www.domain-name.org would not contradict my server’s host name 1: « keyword.host-name.private ». Can someone confirm?

 

With thanks in advance for your attention,

 

Kind regards,

 

Daniela BERNDT

OS X Server

Posted on Dec 3, 2015 7:47 AM

Close
net-plus-ultra

Q: OS X Server 5.0+ > VPN Host Name

  • All replies
  • Helpful answers

  • by Strontium90,

    Strontium90 Strontium90 Dec 3, 2015 10:22 AM in response to net-plus-ultra
    Level 5 (4,077 points)
    Servers Enterprise
    Dec 3, 2015 10:22 AM in response to net-plus-ultra

    DNS should stand for Do Not Skip.  DNS is the foundation of your server and I've been screaming for years against the use of private top level domains when setting up a server.  Bite the bullet and use split horizon DNS.  Today you may say that the server will run Wiki and VPN.  But tomorrow it may run Profile Manager, Open Directory, or Calendar.  You don't know what the future holds so why design with a limitation that you may need to over come?

     

    Ok, that being said, if this system was always going to be a VPN server that provided access to Wiki content and users only accessed it from remote locations, then you still would have a challenge.  Let's walk through it.

     

    You have a server on a LAN at address 192.168.0.2.  It is given a name of server.berndt.local and a Bonjour name of server.local.  Neither of these are routable and are only in context on your LAN.  The double use of .local confuses Bonjour and only makes setup of other services more difficult.  But ok, this is what you have.  Now, you have a fixed public address of 17.18.19.20 and you are port forwarding your VPN ports to allow users to access the server from anywhere in the world.  They configure the VPN client using vpn.berndt.com and now if your ISP alters your IPs you make a public DNS change and no clients need to be altered.  VPN is a port.  It does not care if your host name matches.  So with a public identify of vpn.berndt.com and a private identity of server.berndt.local, the client still connects.  But, aha... What stack do you deliver when the VPN connection is made?

     

    Connecting via VPN provided the client device with a DHCP lease.  These lease will include an IP address, a subnet mask, a router address, and ideally DNS and search domain information.  This data is delivered to give the client the experience of "being on the LAN."  Ok, so what URL do you envision the user's using to connect to your Wiki?  They can not use vpn.berndt.com because that is a public record that terminates at your firewall.  And since you should not be port forwarding http/https they will need to rely on your LAN DNS to route to the resource. 

     

    If this is the logic, then just build proper LAN DNS.  Use a routable domain and TLD.  You don't need to use it, but should you in the future, you will not need to forklift the existing deployment to change course.  Here is an example.  Similar to before.

     

    You have a server on a LAN at address 192.168.0.2.  It is given a name of wiki.berndt.com on your local DNS.  Publicly, you assign vpn.berndt.com to your firewall's public address 17.18.19.20.  Clients on the outside can use vpn.berndt.com to connect to the environment and when they do they are server a LAN stack that includes the DNS server address of your LAN DNS.  Now when the client asked for wiki.berdnt.com they are delivered to the internal server and can input wiki content safely and securely over the VPN connection.

     

    And ah, 6 months down the road your users are requested calendar service and they want it on all devices and don't want to VPN in first.  Now that the LAN DNS is routable, you can define cal.berndt.com on your LAN DNS pointing to a private address and cal.berndt.com on the public DNS pointing to your public address.  Now devices moving between LAN and WAN just work and don't need to be reconfigured due to inconsistent naming.

     

    Probably too much info.  Sorry.  I get on rants with DNS.  Start smart.  Stay away from private domains.  Stay away from .local.  That is for Bonjour.

     

    Reid

    Apple Consultants Network

    Author "El Capitan Server – Foundation Services" :: Exclusively available in Apple's iBooks Store

    Author "El Capitan Server – Control & Collaboration" :: Exclusively available in Apple's iBooks Store

    Author of Yosemite Server and Mavericks Server books

  • by net-plus-ultra,

    net-plus-ultra net-plus-ultra Dec 3, 2015 11:39 AM in response to Strontium90
    Level 1 (5 points)
    Dec 3, 2015 11:39 AM in response to Strontium90

    Hi Strontium90!

     

    Thanks a lot for taking the time to reply, but I have to admit that what you suggest doesn’t help me much, as it is somewhat « out of scope » from a European perspective: first, because what I have in mind is an Intranet for small working groups, second, because I have no use for Bonjour anyway, and third, because .private is - according to my European understanding of Intellectual Property - the very definition of an Intranet!

     

    So the discussion is still open!

     

    Daniela BERNDT

  • by ~jonathan,Helpful

    ~jonathan ~jonathan Dec 4, 2015 3:30 AM in response to net-plus-ultra
    Level 1 (5 points)
    Dec 4, 2015 3:30 AM in response to net-plus-ultra

    net-plus-ultra wrote:

    My server is configured as an Intranet which will provide (native) Wiki services to (future) registered users who will connect through VPN from outside my LAN boundaries.

     

    If you want users to be able to connect from outside your LAN, then you have to specify how those users are going to connect to your Server, that's what the "VPN Host Name" is for. You can keep your host name as "keyword.host-name.private", but you need some way to point your users that are connecting over the Internet back to your server.

     

    One way you could do this would be to set your VPN Host Name to the static IP address of your server, though as Strontium90 suggested, you'll still need to set up DNS (and configure your VPN to use your server for DNS) assuming you want your users to be able to type "keyword.host-name.private" into Safari to access your wiki after the connect over VPN. If you're running behind a NAT (typically a router), you'll also need to configure port forwarding for the necessary VPN ports (TCP 1723, UDP 500, UDP 1701, UDP 4500).

  • by net-plus-ultra,

    net-plus-ultra net-plus-ultra Dec 4, 2015 3:33 AM in response to ~jonathan
    Level 1 (5 points)
    Dec 4, 2015 3:33 AM in response to ~jonathan

    Hi Jonathan!

     

    Thanks for your input, which confirms what I’m thinking. The DNS is already provided for, that’s even quite automatic (as far as my installation is concerned). Since the address that the users will see in their browser after the VPN connection has to be a fully qualified domain name which can’t end with .local or .private, as the server help manual indicates, I am missing something here.

     

    It means either:

    - (Pls. refer back to my initial) point 1: that I have to change my host name, or

    - (Pls. refer back to my initial) question B: that I have to create a new domain name with my registrar (OVH), which I would use as the new VPN Host Name (point 3).

     

    So we’re progressing, but the question is still open!

     

    Thank you,

     

    Daniela

  • by o0OBillO0o,

    o0OBillO0o o0OBillO0o Dec 4, 2015 11:08 AM in response to Strontium90
    Level 1 (34 points)
    Apple Music
    Dec 4, 2015 11:08 AM in response to Strontium90

    ..And I am gonna get your books, Reid. You're very helpful!

     

    Bill

  • by ~jonathan,

    ~jonathan ~jonathan Dec 4, 2015 6:45 PM in response to net-plus-ultra
    Level 1 (5 points)
    Dec 4, 2015 6:45 PM in response to net-plus-ultra

    The DNS is already provided for, that’s even quite automatic (as far as my installation is concerned). Since the address that the users will see in their browser after the VPN connection has to be a fully qualified domain name which can’t end with .local or .private, as the server help manual indicates, I am missing something here.

    Can you clarify what you mean here? Having your host name set is not the same as setting up DNS (there is a service in Server.app under the "Advanced" section called DNS that needs to be on, assuming you want to use Server for DNS). Also, you can definitely use a .private address with a VPN.

     

    As a matter of fact, if you step through the "Edit Host Name…" assistant in Server.app, it will actually recommend a .private address if your users will access your server over "Local Network and VPN".

     

    To address your latest question specifically, this is certainly an option:

    I have to create a new domain name with my registrar (OVH), which I would use as the new VPN Host Name (point 3).

     

    Your VPN Host Name just needs to be set to a host name or IP address that will resolve to your server. A registered domain is the best way to do this (really the only way if you don't have a static IP address). If you're going to go that route, I recommend following Strontium90's advice and "build proper LAN DNS.  Use a routable domain and TLD.".

  • by net-plus-ultra,

    net-plus-ultra net-plus-ultra Dec 5, 2015 4:03 AM in response to ~jonathan
    Level 1 (5 points)
    Dec 5, 2015 4:03 AM in response to ~jonathan

    Hi Jonathan,

     

    What I mean is that in France, where networking is entirely ruled by the European codex of intellectual property, the user experience with setting up a private home business Intranet depends on the kind of ISP that you are registered with: if you are registered with a standard ISP, your modem delivers a dynamic IP address by default, and the user experience becomes a support desk ordeal, or you go for a professional solution (which I did by opting for OVH), and the server configuration becomes much more automated, as the provided IP address is static by default and just needs to be confirmed as such at modem level.

     

    Regarding the VPN Host Name, I also contacted my OVH customer support staff to inquire about an appropriate Fully Qualified Domain Name, as it is first and foremost a matter of interpreting the manuals properly, so as to determine what exactly is missing. So I’ll keep you posted, in order to give this discussion a chance to resolve as well!

     

    With thanks and regards,

     

    Daniela