Jump to content

iannn

Members
  • Posts

    3
  • Joined

  • Last visited

Everything posted by iannn

  1. Hi all, I’m hoping someone can help me sanity check this as I think i'm probably missing something obvious. We recently migrated DHCP from a Windows Server over to our Fortigate 60F. As part of that change, we updated the DHCP scope so clients now receive Google DNS (8.8.8.8 / 8.8.4.4), as we’re planning to eventually retire the DC that currently hosts DNS. Since doing this, about 90% of devices are working perfectly. They can resolve DNS directly against Google without any issues. However, a small number of devices cannot resolve DNS when querying 8.8.8.8 or 8.8.4.4 directly. The strange part is they can browse the web fine if they use our internal DNS server , which has conditional forwarders to Google. All clients are on the same subnet its a flat network: 172.24.xx.xx/22 Gateway/DHCP: 172.24.xx.xx (Fortigate) Switching/WiFi: Ubiquiti 48-port Pro switches + UniFi APs + Cloud Key Gen2 There is no VLAN segmentation, all port profiles are the same, and the same DHCP scope is applied to everyone. Example affected client config looks completely normal: IP in 172.24.xx.xx range Subnet 255.255.252.0 Gateway 172.24.xx.xx DNS: 8.8.8.8, 8.8.4.4, 172.24.xx.xx We have a site-to-site VPN tunnel to our web filtering service. HTTP/HTTPS traffic is sent via VPN tunnel. Firewall policies look like this: internal → to VPN Service: HTTP/HTTPS Action: ACCEPT various SMTP/bypass/monitoring rules internal → wan1 Service: ALL Action: ACCEPT From the policy counters, I can see traffic from the same internal subnet hitting both: internal → toVPN (large byte count) internal → wan1 (smaller but active byte count) So clearly some internal traffic is going out via WAN directly, and some via the Netsweeper tunnel. What I can’t explain is why some clients in the same subnet can reach Google DNS directly and others can’t as the firewall should see them as the same, our internal interface Things I’ve checked: Same subnet, same DHCP scope, same gateway No SD-WAN rules configured No obvious UniFi port/WiFi isolation Swapped cables/ports to rule out physical issues No obvious config differences between working and failing clients Before I make any changes just wondering is there something simply that I have missed? Why would some clients in a flat subnet egress via WAN while others hit the VPN tunnel? Should I explicitly allow DNS on the internal → to (VPN) policy? Is handing out both public DNS and internal AD DNS via DHCP likely causing fallback weirdness here? Any specific FortiGate things I could have missed? Thanks
  2. Is the new DHCP scope on a different VLAN? If so do you need a route on the router with a DHCP relay address?
  3. As of December 2025 doesn't seem to be any progress from Papercut Hive regarding shared pc installs.. We have rolled this out to two sites and its working great for staff as they have 1:1 devices but for students it simply doesn't work - we've had to put in some small unmanaged network printers. It's a shame because other than that it's really good. Has anyone got a reliable method of how to deploy the hive user client reliably through Intune? The company that resells us the product gave us a script to package with the Hive user client but it only works a quarter of the time and then randomly asks users to enter a linking code?
×
×
  • Create New...