0

I'd like to access a web server from both inside and outside my home network. I then have my firewall (pfSense) named as example.com. From within my network, I can access every machine by it's fully resolved hostname (webserver.example.com, jenkins.example.com, nas.example.com, etc). This works great on all my machines.

The issue comes into play when I try to add external access, specifically to my gitlab server. I own a domain and use dynamic DNS to update it to always point to my residential IP address. I've then opened port 443 to point to my internal gitlab IP and added a CNAME entry for gitlab.example.com to point to example.com. This works as expected, I can now access gitlab.example.com from both inside and outside my network.

The issue is that OS X now has a problem resolving the proper IP address. gitlab now resolves to both 192.168.1.XXX and whatever my external IP address is. OS X inconsistently chooses the wrong IP to access. When I ping gitlab.example.com, sometimes I'll see my internal IP, sometimes my external. nslookup always seems to show the internal IP, while Network Utility's lookup function seems to show either both IPs (76.xx.xxx.xxx, 192.168.1.xxx) or just the external IP. This only seems to be a problem when accessing my server from the command line via git. The connection times out because it can't seem to find the server.

Using Chrome, I seem to always be able to access the web client, regardless of which IP get's resolved. Safari can only access the server if the internal IP is resolved. When the external IP is used, Safari notifies me that it can't open the page "because the server where this page is located isn't responding." I can "force" the OS to forget the external IP by flushing the DNS cache (sudo killall -HUP mDNSResponder), which works for a few minutes, but then it goes right back to the external IP.

I'm confused about why this issue is happening. Ideally, I'd like OS X to always use the internal IP if it has the option. But even if it's using the external IP, why wouldn't it be able to access the server? Is my ISP blocking loopback traffic from my IP back to my IP?

The reason I'm posting this question here, is because only OS X seems to have this problem, and I can reproduce it reliably with multiple Macs. Neither Linux or Windows seem to have this problem. Each of those always resolve the internal IP when inside the network, and the external IP outside the network. This is on multiple machines too. I'm not exactly a networking or DNS expert, so any help would be appreciated. It's quite likely that I just have a setting wrong somewhere, but I have no idea where to begin looking.

2

It sounds like what you're trying to do is called Split Horizon DNS, and it can be quite tricky. That said, it sounds like you have quite a bit of it already set up but that the internal DNS is not authoritative for your domain.

If you have not already done so, you need to modify your internal DNS to create a primary zone for example.com. Then, when you query for your domain, the DNS should not look outside for an address.

  • Thanks, that's helpful. Doing some searching lead me to this page. I had already set up Split DNS (Method 2) by adding a host override for my gitlab host, but it apparently doesn't work, at least not with OS X. I'm guessing at this point, it might be a pfSense issue. – Kyle Aug 10 '14 at 21:53
  • I've got it running at home today with my OS X server. The key for me was making it authoritative for the zone and that is done by setting up a Primary Zone in the OS X Server.app DNS. I do not have DHCP or DNS provided by any other device. Then, your web server's CNAME record can point to the machine name. If you do not have the DNS authoritative, queries will go to other DNS servers. I've read mixed messages regarding forwarders but the most definitive answer is you don't need them configured if you have the Primary Zone records internal. – tim.rohrer Aug 10 '14 at 22:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .