How to redirect all requests to the internet from some internal clients to internal server?

Simon, in 'Network Services >> DHCP', search for the MAC on the 'IPv4 Leases' tab.  Hopefully, the associated machine name will allow you to identify the culprit. [;)]

Cheers - Bob 

BAlfson said:

Simon, in 'Network Services >> DHCP', search for the MAC on the 'IPv4 Leases' tab.  Hopefully, the associated machine name will allow you to identify the culprit. [;)]

Unfortunately not, as the people tend to name their computers whatever they want. :)

Note: The setup here is not a company, but a community of 150 people living together. You could say it's an unregulated byod...

Simon

That's a problem.  Until you have a method for identifying people/machines, you have a thankless task.

If you want to block a device from any outside access, do the following:

1. On the 'MAC Address Definitions' tab of 'Definitions & Users >> Network Definitions', create a definition "Malware" containing the MAC address(es) infected with malware.
2. At the bottom of your list of firewall rules, create a rule like: 'Internal (Network) -> Any -> Any : Drop' with, in 'Advanced', 'Source MAC  Addresses: Malware' and with logging selected.
3. Create a blackhole NAT 'DNAT : Internal (Network) -> Any -> Internet : to {non-existent IP}' and do not select 'Automatic firewall rules'.
4. Create another blackhole NAT 'DNAT : Internal (Network) -> Any -> Internal (Address) : to {non-existent IP}' and do not select 'Automatic firewall rules'.

Without a lot of effort on your part, I don't see any other solution.

Cheers - Bob

BAlfson said:

That's a problem.  Until you have a method for identifying people/machines, you have a thankless task.

That's why I want to redirect all http(s) traffic to an internal server, to show a warning message, to come back to my initial question...

BAlfson said:

If you want to block a device from any outside access, do the following: [...]

Well, I did a firewall rule as followed:

• source: {all blocked clients}
• service: any
• destination: internet IPv4
• action: deny

Which should block all (IPv4) traffic, if I get it right (VoIP should e.g. still work ect.). But anyway, my initial question was about how to inform them... Any idea?

Simon

An email to everyone telling them that they will be locked if your security device sees traffic from them that indicates they have a malware infection.

Using IPs instead of the MAC list runs the risk of DHCP assigning the banned IP to another user.  Using a DNAT destination of "Internet IPv4" assumes that the users aren't using the web proxy in Standard mode.  Using a manual firewall rule without the DNAT assumes that Transparent Web Filtering is not activated (see #2 in Rulz). 

I don't know of anything you can use in front of the UTM to do what you want automatically.  There is certainly nothing you can do in the UTM if you don't have a searchable list of allowed MACs and their owners.

Cheers - Bob

In my opinion, blocking all their trsffic is a pretty effective notice.   I assume there is a help desk function for technical problems with the netsork, and that the affected people will use it.

Sounds like you need some policy work to announce terms of service, and some technical work to implement network access control technology.

BAlfson said:

An email to everyone telling them that they will be locked if your security device sees traffic from them that indicates they have a malware infection.

 Seems that this is the only solution. Too bad.
I was wondering if it would be possible to assign a different DNS-resolver to the affected clients to resolve all host names to the internal IP address hosting a notification page. But this is probably not possible either.

BAlfson said:

Using IPs instead of the MAC list runs the risk of DHCP assigning the banned IP to another user.  Using a DNAT destination of "Internet IPv4" assumes that the users aren't using the web proxy in Standard mode.  Using a manual firewall rule without the DNAT assumes that Transparent Web Filtering is not activated (see #2 in Rulz).

I always mark the affected clients as static in the IPv4 lease table, thus I believe blocking the wrong client shouldn't happen. We're afaik not using the web proxy. Thanks though for the tip about the rules, I'll double-check about the Transparent Web Filtering Issue.

DouglasFoster said:

In my opinion, blocking all their trsffic is a pretty effective notice.   I assume there is a help desk function for technical problems with the netsork, and that the affected people will use it.

Sounds like you need some policy work to announce terms of service, and some technical work to implement network access control technology.

Unfortunately your assumption is wrong. I recently had a person who set up their computer before asking me for help. As I mentioned before it's not a company network or the like, but a bunch of people living together in a community. Thus it won't work to set up policies or to technically control network access. I fear I'll have to go with information emails and hope that not too many people with false positives will ask me for help...

"I always mark the affected clients as static in the IPv4 lease table"

Be aware that static assignments are not the same as reservations in Microsoft DHCP.  In the UTM, you must make static assignments outside of the dynamic range, otherwise you risk having two devices assigned the same IP.

Cheers - Bob

BAlfson said:

Be aware that static assignments are not the same as reservations in Microsoft DHCP.  In the UTM, you must make static assignments outside of the dynamic range, otherwise you risk having two devices assigned the same IP.

Thanks for the hint. I assumed, that if I mark them as static in the IPv4 lease table, a corresponding rule is added to the DHCP server of the UTM to prevent a double assignment. If these two functions of the UTM are not coupled to each other, I'd consider this a feature request. :)

Simon