Guest User!

You are not Sophos Staff.

Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 9 replies
  • Subscribers 27 subscribers
  • Views 1231 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Split DNS via internal AD DNS over SSLVPN does not work with Connect based clients

RCA_Sophos

Hi all,

we have the following setup:
- XGS 126, configured for SSLVPN
- The global SSLVPN settings contain the IPs for both internal AD DNS servers and the AD FQDN (i.e. contoso.local)
- The internal DNS is configured for Split-DNS to resolve external DNS names (i.e. webapp.contoso.com) with internal IP addresses (10.51.1.1, 10.51.1.2)

We have the requirement to access applications via a public DNS name (webapp.contoso.com), but through the VPN. That is why we configured Split DNS on the internal DNS servers.

When we connect to the corporate network with the newer Connect client (either Sophos Connect or OpenVPN Connect) Windows gets an NRPT rule saying that the FQDN provided by SSLVPN global settings (contoso.local) should be resolved by the DNS servers provided by global settings (10.51.1.1, 10.51.1.2).

In short: contoso.local --> 10.51.1.1, 10.51.1.2

So internal name resolution works (i.e. printer.contoso.local) but external name resolution (webapp.contoso.com) is directed to the Internet where no record exists because the application should only be available via VPN - so the request fails.
(it is no solution for us to add DNS records with internal IP addresses to the external zone so please do not suggest this ;-)

How can we achieve the goal to send all DNS requests to the internal DNS servers WITHOUT FORCE TUNNELING (Microsoft 365-related traffic must not be routed through the VPN)? Is there a way via DNS request routing?


Best

Ben



This thread was automatically locked due to age.
Parents
  • 0

    Helo RCA_Sophos,

    I assume that you have to carry out some tests with your "webapp.contoso.com" without actually publishing the resource on Interent ...

    two questions:

    1. webapp.contoso.com resolve to internal ip adderess 10.51.1.x ?

    2. can you modify public DNS Record A: webapp.contoso.com to point 10.51.1.x ?

    You can also consider to:

    1. set firewall DNS to internal DNS servers

    2. internal DNS server create a zone "webapp.contoso.com"  and create A record to "." that point to 10.51.1.x

Reply
  • 0

    Helo RCA_Sophos,

    I assume that you have to carry out some tests with your "webapp.contoso.com" without actually publishing the resource on Interent ...

    two questions:

    1. webapp.contoso.com resolve to internal ip adderess 10.51.1.x ?

    2. can you modify public DNS Record A: webapp.contoso.com to point 10.51.1.x ?

    You can also consider to:

    1. set firewall DNS to internal DNS servers

    2. internal DNS server create a zone "webapp.contoso.com"  and create A record to "." that point to 10.51.1.x

Children
  • 0 in reply to GabrieleD

    Hi GabrieleD,

    1. Yes, internally everything works fine, we have created the public DNS zone there. We do not want to have the app accessed from public Internet so no DNS record is set in public zone
    2. As already said, it is no solution to create external records with internal IP addresses. We want to have all DNS requests going to the internal DNS servers
    3. The firewall is already set to internal DNS servers

    The SSLVPN configuration currently pushes the internal DNS servers and the DNS domain contoso.local to the clients. This resolves in only the internal domain (contoso.local) being resolved through the internal DNS servers, everything else goes to the public DNS.
    Is there any way to either add a rule "RESOLVE CONTOSO.COM VIA 10.51.11.1 or 10.50.0.212" or a way with DNS request routing?

    I had a look at DNS request routing and obviously it should work like this:
    - Set the DNS server in SSL VPN configuration to the firewall (should I take the SSL VPN gateway IP here?) and remove the DNS domain
    - Add two routes to DNS request routes to point contoso.local and contoso.com to the internal DNS servers

    Is this correct?

    Best

    Ben

  • 0 in reply to RCA_Sophos

    You can point your firewall DNS (forward) to your internal DNS Server. Internal server resolve internal (contoso.local) and external (contoso.com) zone...

    Consider last 2 my suggestion

    Bye

  • 0 in reply to GabrieleD

    Hi,

    we already do that. The firewall uses the internal DNS servers for DNS resolution but this has nothing to do with SSL VPN configuration. My suggestion is that SSLVPN clients only use the configuration provided by the global settings (DNS servers and internal DNS domain) and not anything behind it - so my question is again, if we need to remove this configuration to let the SSLVPN clients use the firewall's DNS configuration instead - or do I need to point the SSL VPN clients to the firewall as DNS?



    Best

    Ben

  • 0 in reply to RCA_Sophos

    in SSL VPN "split" config -> any contoso.local record use Firewall DNS; the rest pass for other DNS

    in SSL VPN "tunnel" config -> any traffic (also DNS) use that interface

    in second case: If there are a DNS request to other DNS it's necessary to make a SNAT (only for DNS) rule that forwad DNS request to internal DNS server: you need to make a firewall rule to use your ISP (Head Office) to navigate...

    You can make 2 or more SSLVPN profile (one for "tunnel access" -> for use of webapp and one for "split" )

    You can also create a static hostname (on remote PC that need to connect with SSLVPN) that point to internal webapp...

    To my knowledge there is currently no way to specify in the firewall which DNS to use based on the search domain ...

  • +1 in reply to RCA_Sophos

    .. You can manualy modify your .ovpn file ?

    dhcp-option DNS 10.51.11.1
    dhcp-option DOMAIN contoso.local
    dhcp-option DOMAIN contoso.com

  • 0 in reply to GabrieleD

    Hi,

    your last reply seems to be a good workaround - it works exactly as needed, the client now resolves the domain contoso.com via the internal DNS servers provided via the other dhcp-options.

    Thank you so much and have a good day!

    Best
    Ben

Unfiltered HTML