Multiple Locations MAC-Filtering

You COULD sync host definitions with a SUM, but that would also include the network part of the IP-addresses that will hopefully vary from site to site.

Only way to solve that would be using the same network range in all sites and working with NAT for the IPSEC tunnels.

I would prefer copying the mac addresses to a new host rather than doing the NAT thing. ;-)

Maybe there is a way in using the Restful API to change a host object on all UTMs based on it‘s mac address or name, but I never did anything with that.

Meh, I hoped for an automatic process :)

I case of copying: Can you export/import all the static mappings?
Only found something for mac-address lists so far but nothing for mapping.

That would at least reduce the chance of mistyped MAC-adresses.

Hallo isard,

If I understand what you want to accomplish, I think I would do this differently.  Instead of using DHCP with static mappings, put a MAC Address List named "Local Devices" in each site and use that to limit the "Allow" firewall rules to just the MACs in the MAC Address List.  Then, you can have identical rules everywhere.  To prevent use of Proxies (see #2 in Rulz), use some method of authentication and block unauthenticated access.  Will that do what you want?

Cheers - Bob

Maybe. I am not sure.
I will test this and report back.

Thanks for your input!

Sadly neither variant seems to be "bulletproof" :/

DHCP + static mappings
No DHCP IP for unknown devices.
No unwanted connections.
No import/export possibility for ease of use on multiple firewalls (meh...).
Easily avoided by manual IP config (double meh...).

Free DHCP + MAC-list on allow-rules
Free DHCP IP for everyone.
All Firewall-Rules for Client-PCs filtered by MAC-list.
MAC-list can be exported and importet, makes thigns easier on multiple locations.
Even if not within the allowed MAC-list ping on FQDN works (leaves me puzzled for now).
Can not block internet access by the same MAC-list.

Addition
Blocking internet access seems to be an issue with both versions.


After some thinking I will go with both.
First instance: No DHCP IP for unknown devices for blocking unwanted cmomputers.
Second Instance: Even with manual IP config no connection to the delicate stuff (servers, storage,...).
Still missing something reliable to keep unwanted computers away from the internet.

I assume you know that the standard way to prevent unauthorized connections is to use  MAC lockdown for fixed devices and 802.1x authentication for movable devices.  These features are available in better switches.

"Standard" differs a lot :)
To be honest I know no medium sized company that goes for RADIUS (or similar) for example.

In my case there are nearly no static devices/workplaces besides server or infrastructure.
Not much I can do with portsecurity/MAC pairing :/

As for certificate authentication or similar I believe there is nothing configured from past.
Still need to double check this but at least some testing showed no blocking unknown devices at all.
So this is definitly planned but for now I need a quick solution since there is a lot more work that needs to be done.

Still thanks to bring that up even if I can not use that for now :/
There is always something to improve and there is definitly tons of work in network security.

For now I will mark the question as answered because everything else will go far beyond the initial question.

Edit: Most outdated switches will be changed this year, that should be no problem.

"Even if not within the allowed MAC-list ping on FQDN works (leaves me puzzled for now)."

Pinging is regulated globally on the 'ICMP' tab of 'Firewall'.  If you want more granular control, you must disable 'Firewall forwards pings' there and create manual Allow rules.

How does your setup compare to DNS best practice?

You might be interested in a document I maintain that I make available to members of the UTM Community, "Configure HTTP Proxy for a Network of Guests."  If you would like me to send you this document, PM me your email address. I also maintain a version auf Deutsch initially translated by fellow member hallowach when he and I did a major revision in 2013.

Cheers - Bob