UTM using itself for DNS on AWS

I am suspecting it is a type of DOS protection, since my coworker and I connected to the VPN without and issue.  We both started having connectivity issues at the same time.

I don't see anything in the logs yet.

Bypassing the Sophos seems to have fixed the issue.  I am pointing at the AWS DNS instead of the Sophos.  I will see if anyone complains tomorrow.

Correction.  Using the AWS DNS instead of the Sophos has the same issue.  DNS can still resolve, but we are unable to surf the internet.

It's not clear to me what your configuration looks like.  Please compare and contrast with DNS Best Practice.

Is this possibly an oops-I-was-certain-I-had made-a-masquerading-rule situation?

Cheers - Bob

The 'Global' tab of 'Network Services >> DNS' lists "Internal (Network)" (also other internal networks, like "DMZ (Network)" if applicable) as 'Allowed networks'. - Done

On the 'Forwarders' tab, use an Availability Group containing the OpenDNS or Google name servers in 'DNS Forwarders'. 'Use forwarders assigned by ISP' is not checked.* - I'm using the default of AWS' DNS IP address.  "Use forwarders assigned by ISP
Currently assigned forwarders: 10.0.0.2"

In 'Request Routing', the internal DNS is used for reverse DNS of internal IPs (for example if your internal subnet is 172.16.20.0/24, you would have '20.16.172.in-addr.arpa -> {Internal DNS}'. With that, the Astaro can list machine names instead of internal IP addresses in the reports. - Doesn't apply.  I don't need reverse DNS.

Also, in 'Request Routing', so the Astaro can resolve internal FQDNs, add, for example 'yourdomain.loc -> {internal DNS server}'. Do the same for other domains for which you have Forward Lookup Zones in your internal DNS server. - Doesn't apply

Configure Windows Server (or other) DHCP server for internal devices to point at your internal name server for DNS, then the Astaro, then the OpenDNS servers. - Doesn't apply on AWS.

----------

The problems still exist when I don't use the UTM for DNS.  If I point at AWS' DNS server, then problem still happens.  First it works, then later all my users lose connectivity.

My clients are 10.242.0.0/24 and are NATed to the Sophos' IP address.  I'm not sure what masquerading rule to look at.

I'm making an assumption that you are using the UTM for SSL VPN.  Have you set the DNS for the clients at Remote Access > Advanced?

If Scott's question didn't lead you to resolution, please elaborate on the following: In Post #1, you said, "If I use the client's DNS, then connectivity is fine." In Post #6, you said, "Currently assigned forwarders: 10.0.0.2" and that Request Routing did not apply.

Cheers - Bob

Scott,

I have set the Sophos IP address under Remote Access > Advanced.  DNS works.  However, connectivity is later lost.

I have set the AWS DNS IP address under Remote Access > Advanced.  DNS works.  However, connectivity is later lost.

Same problem, different DNS.

BAlfson,

"If I use the client's DNS, then connectivity is fine.":
The current normal configuration is that the client uses their own DNS.  They use whatever their local DHCP is giving them.  Comcast, AT&T, Google, whatever.   In other words, the Remote Access > Advanced is set to 0.0.0.0.

I'm trying to replace the local with the AWS VPC internal DNS.  I'm fine with using the Sophos or AWS, since they will resolve the same answer.

"Currently assigned forwarders: 10.0.0.2":
10.0.0.2 is the AWS internal DNS that DHCP assigns to servers in my VPC, including the Sophos.

"Request routing":
I don't have an internal DNS server.  I'm using AWS.  Do I need to point at 10.0.0.2 even though the Forwarder already points at 10.0.0.2?

Note: DNS does resolve when I update.  /etc/resolv.conf is updated with the new DNS server.  Everything works, then suddenly everyone loses connectivity.  DNS still works when we can't surf the internet.  Lose of connectivity = I am no longer able to hit websites in my browser.

Apparently, we're not asking you the right questions yet - you need someone to log in and  look at this.  If this is supposed to be production soon, you should get Sophos Support involved.  Probably get them involved in any case.  Please post the solution to this conundrum in this thread.

Cheers - Bob