NathanH99 Posted September 17, 2024 Posted September 17, 2024 Hi, We are a trust of 9 Schools, where we have a single domain and single tenancy therefore each site has its own domain controller with its own DHCP but the DC and DNS are connected to the same domain. We use Smoothwall Firewall at each site and have a site to site connection between each site. We use Smoothwalls Cloud Filter on our azure devices to filter them when they are on and off site. To make the cloud filter work we have to a put DNS record into each Schools DNS to tell the laptops the IP of the Smoothwall box local to the site we are on. The issue we are having is that devices are often communicating with other Schools DNS therefore the laptops are getting told the IP of the remote smoothwall not the local smoothwall which then breaks the filtering, I understand if a device fails to communicate with the primary DNS it will then attempt to communicate with the secondary DNS however I am failing to figure out why they are failing to always communicate with the primary DNS. Our current temporary solution is to only push the Local DNS server through DHCP which we are not happy with as it reduces redundancy Anyone with Smoothwall cloud filter have the same issue? or does anyone know the culprit of the DNS issues we are having could be? Thanks in advance
Jonah Posted September 17, 2024 Posted September 17, 2024 If you ping the Smoothwall DNS name from a client repeatedly, does it resolve each sites IP in turn and then repeat over? If so it’s likely DNS subnet prioritisation.
NathanH99 Posted September 17, 2024 Author Posted September 17, 2024 If you ping the Smoothwall DNS name from a client repeatedly, does it resolve each sites IP in turn and then repeat over? If so it’s likely DNS subnet prioritisation. No it returns the Smoothwall IP from the DNS which the current device is connected to each time. We have a new zone on each schools DNS called sw and then within that a CNAME record called secretknock which points to the local smoothwall IP Address which does not replicate therefore each school has there own zone and own pointer to there local smoothwall, therefore when I take my laptop to another site it should request secretknock.sw from the local DNS and tell my laptop what the local smoothwall box IP is however often we find devices are communicating with other DNS servers across the trust and being told the IP of the smoothwall box at another site which is then breaking filtering
5tu Posted September 17, 2024 Posted September 17, 2024 Where are devices getting their DNS server addresses from? DHCP? If so, is there a DHCP server at each site which only gives the address of the local DNS server?
Primus Posted September 17, 2024 Posted September 17, 2024 Is this because they don't share secret knocks like they do with IDex etc?
NathanH99 Posted September 17, 2024 Author Posted September 17, 2024 Where are devices getting their DNS server addresses from? DHCP? If so, is there a DHCP server at each site which only gives the address of the local DNS server? Yes that's correct each site has a DHCP server with server options to push DNS settings, our current only fix is only pushing the local DNS server to clients for each site however if that DNS server goes down then they have no DNS.
NathanH99 Posted September 17, 2024 Author Posted September 17, 2024 Is this because they don't share secret knocks like they do with IDex etc? I don't fully understand what you mean, they all share the same DNS record the clients need to look for being Secretknock.sw however at each site the value this record points to will be there own Smoothwall box which will have a differnet IP per school
Primus Posted September 17, 2024 Posted September 17, 2024 I don't fully understand what you mean, they all share the same DNS record the clients need to look for being Secretknock.sw however at each site the value this record points to will be there own Smoothwall box which will have a differnet IP per school So because they don't share the secret knock they're not knocking on the correct Smoothwall to be able to have their temporary filtering exeption because they've got the cloud filter client/extension working is what I mean.
NathanH99 Posted September 17, 2024 Author Posted September 17, 2024 So because they don't share the secret knock they're not knocking on the correct Smoothwall to be able to have their temporary filtering exeption because they've got the cloud filter client/extension working is what I mean. Ah apologies yeah thats correct devices are sometimes going to the wrong School DNS then knocking on the wrong smoothwall
Primus Posted September 17, 2024 Posted September 17, 2024 Ah apologies yeah thats correct devices are sometimes going to the wrong School DNS then knocking on the wrong smoothwall @tom_newton - I've flagged this to support before and it could easily be fixed by synchronising secret knocks in the same was IDex synchronises. 1
NathanH99 Posted September 18, 2024 Author Posted September 18, 2024 @tom_newton - I've flagged this to support before and it could easily be fixed by synchronising secret knocks in the same was IDex synchronises. We have also raised it with support however was told there was nothing Smoothwall could do so id be really interested in how synchronising secret knocks work and if that is our solution, Thanks!
Primus Posted September 18, 2024 Posted September 18, 2024 So the secret knock tells the Smoothwall to ignore the requests coming from the device for the defined period so that it's not dual filtered (by the appliance and the extension) and it prevents double notifications from the on prem and the cloud safeguarding notifications. All Smoothwall would need to do is store the secret knock IPs in a database that could replicate - they already do this with IDex.
tom_newton Posted September 18, 2024 Posted September 18, 2024 We have thought of this, but worried that we wouldn't get the latency of change fast enough. Could be something that happens post Maiden.
NathanH99 Posted September 18, 2024 Author Posted September 18, 2024 We have thought of this, but worried that we wouldn't get the latency of change fast enough. Could be something that happens post Maiden. Is there another solution we can try which is different to what we are currently doing?
Joeloman Posted September 18, 2024 Posted September 18, 2024 It is always good to separate the traffic on different physical networks and/or VLANs. Then it is also easy to avoid double filtering. However, it is important to ensure that only school computers with Cloud Filter installed can connect to that network. Check this KB:https://kb.smoothwall.com/hc/en-us/articles/360015978080-Smoothwall-Filter-Firewall-Preparing-for-Cloud-Filter-to-avoid-Double-Filtering
Primus Posted September 18, 2024 Posted September 18, 2024 It is always good to separate the traffic on different physical networks and/or VLANs. Then it is also easy to avoid double filtering. However, it is important to ensure that only school computers with Cloud Filter installed can connect to that network. Check this KB:https://kb.smoothwall.com/hc/en-us/articles/360015978080-Smoothwall-Filter-Firewall-Preparing-for-Cloud-Filter-to-avoid-Double-Filtering It depends - with resilient networks and dynamic routing it's not always possible. I can predict where traffic from a given vLAN will emerge 99% of the time but if we have a failover of the node that traffic flows to then it will route to another node which is up - at which point it'll be knocking on the wrong Smoothwall. I find it strange that IDex replicates information within the nodes but the secret knocks don't.
NathanH99 Posted September 19, 2024 Author Posted September 19, 2024 It depends - with resilient networks and dynamic routing it's not always possible. I can predict where traffic from a given vLAN will emerge 99% of the time but if we have a failover of the node that traffic flows to then it will route to another node which is up - at which point it'll be knocking on the wrong Smoothwall. I find it strange that IDex replicates information within the nodes but the secret knocks don't. Thanks for all your help and advice on this! I think I have come to the conclusion there is no fix from Smooth wall on this one and I will need to look at a method to ensure the device hit the correct DNS every time or look at doing it through VLAN's
tom_newton Posted September 20, 2024 Posted September 20, 2024 Is there another solution we can try which is different to what we are currently doing? SPlit brain DNS might do it for you? https://learn.microsoft.com/en-us/windows-server/networking/dns/deploy/dns-policies-overview 1
Primus Posted September 20, 2024 Posted September 20, 2024 I'm honestly still not sure why the secret knocks cannot replicate - you replicate lots of other stuff like IDex.
tom_newton Posted September 20, 2024 Posted September 20, 2024 The idex system wasnt up to is - that's been replaced in Maiden, so we might be able to do so 1
NathanH99 Posted September 23, 2024 Author Posted September 23, 2024 We are now looking to use https://learn.microsoft.com/en-us/windows-server/networking/dns/deploy/primary-geo-location and from testing seems to be working, this fixes our smoothwall issue however not our DNS issue
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now