Internal servers accessible via subdomain.domain.org from outside LAN, but not inside.

Hi all. I'm running Sophos XG v18 and have been building things out a bit for my home setup, but just recently I hit a snag that I'm having a lot of difficulty figuring out. I've read a lot of guides that suggest this is a common thing and pretty approachable however I'm still held up. Unsure if it's a v18 thing as a lot of results pertain to v17.x or if it's my lack of understanding (clearly the latter).

I have a wildcard certificate from Lets Encrypt that has been uploaded to Sophos XG. I also have a domain, call it example.org, which is registered and a DDNS service that keeps that in check. I have several internal services/VMs that I want to make accessible via subdomains, e.g. cctv.example.org, cloud.example.org, etc. In some cases these services run their own local self-signed SSL certificates (in one case I can't even find a way to disable it), so perhaps that's a contributing factor here.

Using the cctv platform as an example here, my process from start to finish is as follows:

1) In System >> Hosts and Services, I created a new IP host. Name = cctv.example.org, IP is the local LAN IP of that server.

2) In Configure >> Network >> DNS >> DNS host entry, I created a new entry where host/domain name is cctv.example.org, entry type manual, IP local LAN IP of that server, TTL 60, Weight 1, Publish to WAN and Reverse DNS lookup both remain unchecked.

3) In Protect >> Web server >> Web servers, I created an entry where name is CCTV and host is cctv.example.org, HTTP, port 8800 (what the CCTV server uses).

4) In Protect >> Rules and policies >> Firewall rules, I created a rule where Action = Protect with web server protection, hosted address = Port2 (WAN), listening port 443, HTTPS checked/HTTP redirect checked, domains = cctv.example.org, Lets Encrypt wildcard cert selected, and the "CCTV" entry selected under Protected servers >> Web servers.

With this in place from outside the LAN I can hit cctv.example.org and I get immediate access with the assigned Lets Encrypt SSL cert. I don't have to do :8800 or anything of that nature. Works absolutely fantastic and exactly what I wanted. The problem is from inside the LAN that exact procedure does not yield access. In Chrome for example I get "hmm can't reach this page, cctv.example.org took too long to respond -- ERR_CONNECTION_TIMED_OUT.

Within Firewall rules >> Add firewall rule, I've also tried "server access assistant (DNAT)" but it didn't yield any difference in behavior. I've toyed with the NAT rules and MASQ but the most I've been able to do is take down my entire WAN connection which prompted a VEEAM rollback as I made the mistake of not pulling a Sophos XG backup config prior (I know, I know...)

If I could figure out one of these services I can likely get all of them working, but I'm growing increasingly confused by some of the forum posts I've read. Some folks suggest I just need to set up DNS host entries, which I did and seems to work for external access to cctv.example.org, but not inside. I've read about hairpin NAT but half of the articles folks have linked to that appear to go to Sophos documentation end up 404'ing me. Other folks seem to want to be able to access cctv.example.org but have it entirely redirect/change to internal.ip.of.cctv:8800, whereas I'd like internal and external to just be cctv.example.org 100% of the time.

I'm missing something... and I'm sure it's something obvious... if anybody knows I would be greatly appreciative! 



Added TAG
[edited by: emmosophos at 10:18 PM (GMT -7) on 8 Apr 2021]

Top Replies

Parents
  • Hello,

    Can you send a picture of both DNS Host Entry and the WAF Configuration?

    In Configure >> Network >> DNS >> DNS host entry, I created a new entry where host/domain name is cctv.example.org, entry type manual, IP local LAN IP of that server, TTL 60, Weight 1, Publish to WAN and Reverse DNS lookup both remain unchecked.

    Remove this DNS Entry, this is the reason your local devices can't connect to the WAF.

    The problem is from inside the LAN that exact procedure does not yield access. In Chrome for example I get "hmm can't reach this page, cctv.example.org took too long to respond -- ERR_CONNECTION_TIMED_OUT.

    Your local network devices are connecting directly to the CCTV server instead of the WAF.

    Also, there's no need for any NAT or Firewall Rule for the WAF, if you created one, please delete them.


    If a post solves your question use the 'Verify Answer' link.

  • I know I said I was expecting it to be obvious but I didn't expect it to be this easy... 

    So I removed the DNS entry as you suggested and, at least according to my VPN+RDP session home, my home desktop can now access everything internally via the subdomain.example.org addresses as I was hoping. 

    This is all great and I'm super happy it works (thank you!) but... how? It's clear that having a DNS host entry was somehow stepping on the process, but is the rationale here that having a DNS host set up conflicts with the, essentially duplicated, entry within the Web Servers field?

  • Here's what just happened:

    Your browser sends a DNS query for the CCTV subdomain, the firewall responded with the custom response you've inputted on It before.

    Since on that custom DNS Entry you've made has giving the IPv4 for the CCTV Device (Not the WAF), the browser tried to connect directly to the CCTV device instead of the WAF.

    By removing the custom Entry, the Firewall made the DNS query directly at some public DNS Server, which gave you the correct IPv4 so the browser could connect at the WAF.


    If a post solves your question use the 'Verify Answer' link.

  • One thing, I highly recommend you to not expose things such as CCTV for the entire Internet.

    If you can, setup a Local-Only WAF; You can do this by using any "LAN Zone" Interface (Port) while configuring the WAF, then setup a DNS Entry with the IPv4 of that Interface.

    After It you should use SSLVPN to access the WAF or any other local service.


    If a post solves your question use the 'Verify Answer' link.

  • Ah, I see. Thank you for the explanation! It's great to see it working but the mystery of the 'why' is always helpful to know in more detail. Appreciate it!

    Also, noted about the CCTV platform. I actually am using that as a "test" in this case. I don't plan on keeping this setup employed permanently for CCTV since video surveillance platforms are, sadly, anything but secure.

Reply
  • Ah, I see. Thank you for the explanation! It's great to see it working but the mystery of the 'why' is always helpful to know in more detail. Appreciate it!

    Also, noted about the CCTV platform. I actually am using that as a "test" in this case. I don't plan on keeping this setup employed permanently for CCTV since video surveillance platforms are, sadly, anything but secure.

Children
No Data