Problems blocking DHCP

I’m having problems blocking DHCP.

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 =
Source Port = 68
Desination IP =
Desination IP = 67

However, computers at site B are still receiving dynamic IP addresses from the DHCP server at site A.

Any ideas?

Try to set source port to range 67-68.

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

Thanks for the reply.

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 network. Each site uses it’s own /24 subnet (Site A is, and site B is, however this is a “gentleman’s subnet” as the hosts are actually configured with a /16 subnet so that they can all communicate.

What firewall do you have running on the server then ? and what’s the server OS ?

It’s Comodo version 3.8.64739.471

The OS is Windows XP 32 bit.

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.

It will still work because the firewall rules only apply locally on the VPN server. The VPN server is only “between” different sites.

It’s not “between” different hosts at the same site.

The problem appears to be that Comodo thinks it’s blocking this DHCP traffic, but it really isn’t.


I think my rules are blocking all DHCP traffic but I’m not. If I’m not, I don’t see what I’m missing.

So the XP host is acting like a gateway, is it routing on a stick with one interface or is it multi homed using multiple interfaces ?

I’m afraid I’m not familiar enough with that terminology to directly answer that with any certanty.

The XP host is connected to a router via ethernet.

It is running a VPN application that creates a VPN tunnel over the internet.

The VPN application uses a virtual “TAP-Win32 Adapter” installed on the XP host.

The TAP adapter is bridged by the OS to the real physical NIC.

The VPN connection functions as a switch.

Some testing I’ve done.

As a preface, I now have 2 individual rules.

Rule 1 is to block log UDP from;

Source = Any
Desination = Any
Source Port = Any
Destination Port = 67, 68

Rule 2 is to block and log UDP from;

Source = Any
Desination = Any
Source Port = 67, 68
Destination Port = Any

From a separate host on the same physical LAN as the XPHOST with Comodo;

When I " telnet XPHOST 67" or " telnet XPHOST 68" I see the traffic as blocked in the Comodo logs.

From the XPHOST to a separate host on the same physical LAN as the XPHOST with Comodo;

When I " telnet separatehost 67 " or " telnet separatehost 68 " I do not see the traffic as blocked in the Comodo logs.

Now what I don’t know is, does this mean the traffic OUT to port 67 or 68 from XPHOST is not blocked?


Do is imply not see it in the logs because the logs are called “intrusion attempts” which implies it ONLY logs INCOMING and does NOT log OUTGOING??

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 stuff it could be it’s not logging/blocking it.