I have a VPN server with connections to multiple different points. The VPN creates a transparent Ethernet over Internet connection, and as such, DHCP at each site is “bleeding” out to other sites.
Occasionally, a computer at site B will receive a dynamic IP from site A’s DHCP server.
So, as a solution I’ve implemented Comodo firewall on site A’s server and created a global rule to block DHCP traffic.
The Rule is;
Deny and Log
Protocol = UDP
Direction = In/Out
Source Address = Any
Desination Address = Any
Source Port = Any
Desination Port = A Port Range [67 - 68]
The logs show the rule firing.
For example;
Action = blocked
Protocol = UDP
Source IP = 0.0.0.0
Source Port = 68
Desination IP = 255.255.255.255
Desination IP = 67
However, computers at site B are still receiving dynamic IP addresses from the DHCP server at site A.
Maybe it’s a solution to use a different subnet for VPN Users and let the VPN Server handle the DHCP for the VPN Clients, so every location will have it’s “unique” address range.
If this is a “flat” network it would also be possible to receive an ip address from a host on net A from the server on net B
Initially the rule contained both source and destination ports to be 67-68, however I discovered that this creates an “AND” condition where the traffic must be Source = [67,68] AND Destination = [67,68]. Sometimes I see DHCP traffic with a random high-port source so I changed Source to be ALL.
I’ll write a second rule such that source = 67, 68 is blocked.
I tried using the “port set” feature but that didn’t seem to work for me either.
Abou the VPN, I don’t really have VPN users per-se. The purpose of the VPN is to create a virtual LAN over the internet between several sites, allowing all hosts (exceptions are handled locally) at every site to be peers.
All hosts are on the 192.168.0.0/16 network. Each site uses it’s own /24 subnet (Site A is 192.168.2.0/24, and site B is 192.168.3.0/24), however this is a “gentleman’s subnet” as the hosts are actually configured with a /16 subnet so that they can all communicate.
If this works this will render your DHCP server useless on location A because you can’t distinguish between a computer on site A and on site B by the DHCP discover process.
Well I’ve managed to answer my own question here. Yes the logs will reflect outgoing connections. The reason I’m not seeing my Telnet traffic out as blocked is because the application rule for Telnet supercedes the Global rule to block traffic on those ports, which I also understand is normal for Comodo.
Unfortunately this means I have no way to test the global rule for blocking outbound traffic on those ports because any means by which I would try would fall under application rules to deny or allow and action on that before the global rules ever come in to play.
I can’t find it, but is there any way to have Comodo ignore all application rules while still applying global rules?
You can try to create an application rule for WOS Windows Operating System,
Open firewall policy, click Add, Select running process “Windows Operating System” and set some app rules for 67/68 with logging, maybe you can use that to see if it logs more then the previous solutions…
There are some firewalling exceptions for Windows Operating Systems traffic that is called a pseudo process.
Because of the dst 255.255.255.255 stuff it could be it’s not logging/blocking it.