Openvpn – blocking dhcp remote dhcp requests with ebtables

[divide]

Hi,

I think that this is pretty common issue when using openvpn connection and there are multiple dhcp servers in different sites.

It is possible to block unwanted remote dhcp requests with ebtables, but it just gives me this error:

“The kernel doesn’t support the ebtables filter table.”

My commands are valid because I can use ebtables filtering in some of my dd-wrt routers.

ebtables -I INPUT 0 -i VPN00 -p IPv4 –ip-protocol udp –ip-destination-port 67:68 -j DROP
ebtables -I OUTPUT 0 -o VPN00 -p IPv4 –ip-protocol udp –ip-destination-port 67:68 -j DROP

So obvioisly there should be this filter also added or is there any other way?

[imported_fulvio]

Zeroshell does not support directly ebtables but use a netfilter patch that allows to use iptables also on bridged traffic. You can use the web interface of the firewall to block the dhcp requests.

Regards
Fulvio

[divide]

Do I have to install netfilter patch or is it already integrated? I have tried to use “LAYER7 l7proto dhcp” config in webui to interface VPN00, but it doesn’t work. I cannot block all the dhcp request on my BRIDGE00 because my local machines uses Zeroshell’s DHCP.

[dr1]

I was running into a similar situation, and if you hand load the ebtables module you can use it from the command line (at least now, i realize this is an old post)

I got a question about the interface though. The ‘Apply To: Routed or bridged interfaces’ only comes up for the FORWARD chain. Can this be applied to the INPUT and OUTPUT chains as well? And if it was, would it use some ebtables module to be able to block things like DHCP with the interface?

because while you can add a rule with iptables to the input chain, to block DHCP, and it will get triggered. it wont work, because dhcpd and iptables are basically operating at the same layer.

[ppalias]

Don’t think so. DHCPD is an application working on L7, while iptables can block from L2 upwards. If you have trouble blocking DHCPD show us the rule here to see what is wrong.

[dr1]

I have no problem with the rule, the rule catches it fine. iptables is just incapable of blocking the traffic dhcpd is sending and receiving.

You have todo a little searching because people tend to give advice about stuff they havent actually played with before, but, lol. Its my understanding iptables cannot effect the raw sockets dhcpd is using for communcation.

I had an old firewall rule in place from a prior experiment set to block all dhcp traffic, didnt realize it and the counters were up to like 300.. of course it never stopped a shred of dhcp traffic the rest of my network worked fine, lol. After I did a little research i figured I would chime in, and also to find out if whatever supposed module iptables is using to replace ebtables functionality, if it would actually work in this case.

[ppalias]

Dhcpd is not using raw sockets. It is using udp/67-68. So back to the beginning to tell us what your problem is and what you want to do.

[dr1]

All I can tell you is I suggest you go ahead and perform a little experiment and see for yourself, or you will just be added to the giant list of people who put their foot in their mouth, lol. A google search will show you this.

http://lists.netfilter.org/pipermail/netfilter/2002-May/034387.html

http://ubuntuforums.org/showthread.php?t=1210187

[dr1]

Chain INPUT (policy ACCEPT 5618 packets, 460K bytes)
pkts bytes target prot opt in out source destination
8 2640 DROP udp — any any anywhere anywhere udp dpts:bootps:bootpc

Chain OUTPUT (policy ACCEPT 9077 packets, 2639K bytes)
pkts bytes target prot opt in out source destination
3 984 DROP udp — any any anywhere anywhere udp dpts:bootps:bootpc

IP Address MAC Address Client Hostname State Start Time End Time
10.3.250.20 00:24:b2:48:a6:ee SONYUX active 2010/08/25 11:53:51 2010/08/25 19:53:51

root@gateway root> date
Wed Aug 25 11:56:39 EDT 2010

im always trying to make sure im not putting my own foot in my own mouth either, so there you go 🙂
There used to be an option in 2.4 called ‘CONFIG_FILTER’, that may be enabled in 2.6 by default because its no longer an option, however it doesnt seem to apply to iptables. As the option itself in the description says its ‘ok to leave disabled’ since unless your a programmer you wont be utilizing it anyways, lol.

[ppalias]

I did a little testing and you are right that packets pass the firewall. However the packets are not raw, at least the values in the fields show IP protocol, udp port 67 and 68. Check the capture file that I got http://rapidshare.com/files/415207204/dhcp_c.pcap.html
I had captured dhcp packets many times, this is why I argued with you about packets being udp and not raw. I don’t understand the way that dhcp client is programmed, but I accept the explanation that you have given from the links. My question is the following though; what will happen if isc-dhcpc tries to acquire IP address from another server, such as cisco or microsoft? Does it still send raw or udp?

[dr1]

I dont know. Looking at the source they seem to have included possibly 3 different methods of communicating. Its my understanding if they use normal udp alot of windows clients wont work.

I did a bit more reading and it seems as though iptables is essentially getting a ‘clone’ packet, thats why the rules are triggering.

Its extra odd that enabling the firewall rules trigged a “send_packet: Operation not permitted” error from dhcpd, though for only some of the packets it send, and yet the client did receive a fresh new ip anyways.

Good information on the subject is not easy to find.

[dr1]

I’ll also mention ebtables would not have helped the original poster I dont believe, since ebtables will only work on bridged interfaces. I’ve used it on dd-wrt myself though on the bridged interface with success.

[ppalias]

Weird thing is that I didn’t find any raw packets in the whole capture of the dhcp process. Anyway, maybe the dhcp packets were transmited automagically 😀

[dr1]

i think raw in this case just means not using the normal tcp/ip stack? dhcpd on zeroshell is utilizing LPF(linux packet filter) to send the packets, which is still a udp packet but outside of iptables reach.. i guess. shrug.

[ppalias]

In raw sockets the transport layer is bypassed and packet headers are stripped off. Despite of that Wireshark is able of capturing raw packets as well and it is sparking my curiosity why it didn’t capture it as raw.

[Author]

Posts