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

Routing Site-to-Site VPN Traffic on same Domain Computers

Currently, I have a Site-to-Site VPN, with split tunnels to specific IP's and networks, setup on both Sophos firewalls and they are working fine. BIGGEST THING TO REMEMBER, the branch office needs to have their computers on our internal Domain.

The branch office needs to see the DNS server, which it does, but cannot translate names of devices within the VPN without giving the Firewall the DNS server as its primary DNS provider.

The problem with the DNS server being the primary provider, is that the internet traffic will be routed through the VPN.

I need the Internet traffic to be separate from the VPN traffic and still allow for VPN traffic to have DNS resolution. I feel this may be a NAT issue, or possibly a rule/policy problem. I can't seem to get a straight answer anywhere.  

Any ideas? 



This thread was automatically locked due to age.
Parents
  • Based on your description, your internet traffic is not being routed via the VPN that has the DNS server on it, just the DNS queries.

    Here is how to deal with this issue. Configure your DNS as you normally would using ISP, public, or whatever DNS server you want to use for your Internet DNS queries. Then configure a "DNS request route" with the domain name you need the remote office to query. The target is the DNS server you want for the internal DNS queries.

    Configuring this will use your standard DNS configuration for all DNS queries, except for the domain you configured the DNS request route.

    This is located at Network > DNS then at the bottom of the menu is DNS host entry.

    The one issue I have found out about this I am uncertain how or why the Sophos uses a particular interface to make the requests to the DNS request route. It seems to choose one randomly, so you may have to do some log or packet captures to determine what interface is making the requests of your DNS server via the VPN. 

    Resulting DNS request map.

Reply
  • Based on your description, your internet traffic is not being routed via the VPN that has the DNS server on it, just the DNS queries.

    Here is how to deal with this issue. Configure your DNS as you normally would using ISP, public, or whatever DNS server you want to use for your Internet DNS queries. Then configure a "DNS request route" with the domain name you need the remote office to query. The target is the DNS server you want for the internal DNS queries.

    Configuring this will use your standard DNS configuration for all DNS queries, except for the domain you configured the DNS request route.

    This is located at Network > DNS then at the bottom of the menu is DNS host entry.

    The one issue I have found out about this I am uncertain how or why the Sophos uses a particular interface to make the requests to the DNS request route. It seems to choose one randomly, so you may have to do some log or packet captures to determine what interface is making the requests of your DNS server via the VPN. 

    Resulting DNS request map.

Children
  • If the Site-to-Site VPN is up, and the primary DNS server is our internal DNS, it is definitely using our internal DNS server to query and navigate internet searches. This means internet traffic is flowing through the VPN with every internet translation. If I were to disconnect the VPN, and not have a Comcast DNS as the secondary DNS, the computers under the firewall would not lose connectivity, but they would not be able to search through the internet using a browser. You could still ping a domain by IP, but there would be no translation.

    We also have a Citrix webpage which loads differently depending on if you are inside or outside the network. It loads that webpage like you are on the internal network when the primary DNS is our internal DNS.

    From my understanding, the request route will only work when coming from a external domain to an internal. The DNS Request Route does not work because the computer, under the remote firewall, is joined to the internal domain and is connecting to our domain while using the VPN. 

  • You are misguided by what DNS does. The traffic does not flow through the DNS server, it just resolves names to IP addresses, and other things. Your still connected to the internet with the VPN down, you just cannot reach your DNS server to resolve names to IP addresses. If you try to connect to a service via IP, it will still work.

    But that isn't really your issue.

    The DNS request route is specific to a domain. It tells the XG to request name resolution for the specified domain from the specified IP address.

    Because you mentioned a split DNS scenario for your public domain you may also need to add an additional DNS request route for the public domain or just DNS host entries for specific hosts.

    This is the answer to your question, I use this method at all my locations.

    Side Note: Your traffic is dictated by your firewall rules, static route and SD-WAN policy routing rules, which doesn't sound like the issue in your description of the issue, as your only changing the DNS setting.

  • What would the Request route that needs to be setup on the main XG firewall be? 

    The main XG gets it DNS from the internal DNS server. Would the domain be internaldomain.local and the target be the internal DNS server? Or would the target be the IP of the remote site? 

    The remote XG would have the domain as internadomain.local and the DNS server? I would assume. 

  • The picture I drew for you shows the XG at the remote site with the DNS Request route.
    DNS request route
    Domain = internaldomain.local
    Target = 192.168.1.2 (this is your DNS server for your internaldomain.local domain)

    You don't need to set one up at the main site, if you are happy with your current DNS configuration there. But if you want folks to be able to surf while your DNS server may be down, then you can add the very same DNS request route to the main site as well.

    Please keep in mind that you may have to troubleshoot what XG interface is making the DNS requests to the Internal DNS server and make adjustments to firewall rules and or vpn configurations.

  • Right now, I have static DNS on the remote site setup to have 75.75.75.75 and 75.75.76.76. This is normally what is given to it from Comcast. I created a Request route,

    Domain = internaldomain.local

    Target = Internal domain server

    On the computer under the remote firewall, I can ping the IP addresses that the VPN tunnel is setup to connect to, but I cannot ping the host names of those servers. There are only two interfaces that can make this request, port 1 = LAN and port 2 = WAN. If DHCP is being given out to by the firewall, wouldn't that mean that LAN would be the automatic interface it would use to process DNS Queries? My firewall rules are basic, a rule for Lan to VPN tunnel, a rule from VPN tunnel to LAN, and a rule for LAN to WAN. 

    My biggest question is, if the computer itself is joined to our internaldomain.local, would the request route work for it? The firewall may be able to process DNS correctly, but since the computer itself is joined to our internal domain, wouldn't that mean it needs to have the Internal DNS as the primary? 

  • Per windows domain rules one would think that it must be the primary DNS server. The DNS request route handles directing name resolution for your internal domain to your internal domain DNS server.

    The Remote Workstation must use the remote XG as its primary DNS.

    The Remote XG DNS should use Comcast DNS servers like this...

    The Remote XG should have the DNS request route you specified using the Internal DNS servers IP address.

    This configuration will allow you to surf the web if the VPN is down, yet keep the domain workstations connected to the windows domain while the VPN is active.

    Now if you have configured this like I stated, and you have no name resolution for your internal domain, then you must packet capture the DNS traffic that is directed to your internal domain IP on the remote XG, to determine what interface is making the requests, and that its allowed to traverse your VPN. As I stated I do not know how it decides as it seems to be different on different XGs. It also changed on one of my XG's after a firmware update.

  • If I do a diagnostic on the firewall, and none of the interfaces can ping our hosts' by name, but for some reason it can ping a hostname.internaldomain.com without an interface selected. What does that mean? Port 1, which is our LAN port, is handling DNS, I can see it during a packet capture. Sorry, this is a little confusing for me. Since you are vouching this works, and it is dependent on the interface it uses, a site-to-site IPSEC VPN does not create a separate interface on the XG. 

  • The inbuilt utilities like ping, or the dns check do not properly use all the DNS configurations. (at least in the past, it looks like your first image it is working)

    If possible please share your configuration of the  DNS page, and the host entity you are using as your target in the DNS request route.

    Next you will need to setup a packet capture the XG GUI packet capture on the Remote XG is fine.

    Define it like this "host <ip of internal DNS at the main site> and port 53". This will show you the traffic attempting to touch your internal DNS form your remote XG. If your DNS request route is properly configured, it will show you one of the Remote XG interface IPs as communicating or attempting to communicate with your internal DNS server.

    While the packet capture is capturing, from the remote work station attempt to ping the internal domain, not a host. Remember the remote workstation must use the remote XG as its Primary DNS server.

  • DHCP uses the device's DNS settings. If I do a normal packet capture, and filter out packets that were going through port 53, I only see the Comcast DNS being a destination. 

  • Your first picture with the ping, looks like it's pinging correctly to the host name.

    Thanks for mentioning the DHCP setting, Uncheck "Use devices DNS settings" and enter your XG's IP address in primary DNS.

    Refresh your DHCP on the workstation to ensure the DNS is using the XG, not Comcast.

    When packet capturing on the remote XG and only specify your internal DNS IP and port 53.

    Then ping from workstation to the domain, no host.