A lot of devices use web ports and protocols to "call back" to their services. Cameras, franking machines, printers and IoT (Internet of Things) devices are all examples of that. We call these types of devices "headless devices" in this article. Since web ports are almost guaranteed to be open in any network, they have become the standard for communications for almost any type of device. This can cause some issues when proxies are used, transparent or otherwise, and authentication is part of the setup.
IP addresses for headless devices
Since we cannot rely on authentication for headless devices, we need to know their source IP addresses for any type of solution to be applied.
Assigning a specific subnet to devices could be one option and then create a specific policy for that subnet. Sometimes this isn't possible, or at least not possible for all the devices, as some might need to be on specific networks to respond to broadcasts from other devices, trying to find them.
Another options is to assign the static IP addresses to those devices, either manually on the device or by MAC address in the DHCP service. This requires a bit of housekeeping. Finding the method that requires the least amount of maintenance is important, this isn't something we want to have to maintain on a daily basis.
Options for headless devices
Once we have the IP addresses for those devices, create a location in "Guardian - Policy objects - Locations" and add the IP addresses to the location. We can then look at the available options. In no particular order:
- Use a location based policy in the proxy configuration to apply a specific group permission setting for the devices. Locations are powerful tools and can be used both in proxy policies (non-transparent as well as transparent) and in Guardian web filter policies. In a proxy authentication policy, set the authentication method to "No Authentication" or "Core authentication", set the "Where" to the location defined for the headless devices and finally, in the third step, select a group permission to give those requests. A specific group can be created for them or an already defined group can be used. In this way, specific group permissions can be applied to the headless devices.
In addition to proxy authentication policies, web filter policies can also be applied based on location, as well a group. Using both of these options will give you a lot of flexibility on how to handle proxy permissions for headless devices.
- Bypass proxy completely for those devices in the transparent proxy settings. To bypass the transparent proxy we need to tell the proxy itself to not intercept traffic coming from specific IP addresses. This can be found in "Guardian - Web filter - Exceptions". Add all IP addresses into the source exceptions field. Adding IP addresses into the source exceptions doesn't preclude the same IPs from using the non-transparent proxy using static proxy settings.
Note: When traffic is bypassing the transparent proxy no filtering or logging will be done in the web filter. The firewall rules now apply to the traffic so make sure outgoing traffic from those IPs are allowed on the web ports if the Smoothwall is being used as firewall.
Bypassing HTTPS inspection for headless devices is almost a guaranteed requirement to get them to connect properly through the proxy. It's very unlikely they'll be using "proper" HTTPS and certificate validation. So always create a HTTPS inspection bypass rule for the location in Guardian too.
For the most part, having a log of what these devices do and how often they communicate with external resources, is a good idea. Filtering rules don't need to be strict for these devices because no users will be browsing from them, but logging what they do can be useful, both for bandwidth management and for incident reporting. For that reason, bypassing the proxy should be used sparingly and that goes for any type of HTTP(S) traffic.