From: Eddie <eddies@softhome.net>
To: netfilter@vger.kernel.org
Subject: Blocking DHCP with ebtables
Date: Sat, 12 Sep 2009 13:19:54 -0700 [thread overview]
Message-ID: <4AAC026A.9000208@softhome.net> (raw)
[-- Attachment #1: Type: text/plain, Size: 3014 bytes --]
I have a network bridging two offices using OpenVPN. I am running a DHCP
server on both sides so if the tunnel goes down, both sides will still
have internet access. (Both sides run Slack/Shorewall/OpenVPN)
I have the obvious problem with stopping DHCP packets from crossing the
bridge. I use the below ebtables example, but something is wrong. Under
testing, it appeared to work, but I under deployment, am seeing windows
host on the main office side getting dual gateways, and/or the dns
server from the remote side. It's really strange stuff.
Here is the ebtables rules I use on the remote side only. I am not sure
if I need anything on the main side since I figure if this blocks all
dhcp traffic across the bridge, then all should be good.
# Clear ebtables
ebtables -F
ebtables -X
# Drop everything and build up Input and Output to accept IP and ARP
ebtables -P FORWARD DROP
ebtables -P INPUT DROP
ebtables -P OUTPUT DROP
ebtables -A INPUT -p IPv4 -j ACCEPT
ebtables -A INPUT -p ARP -j ACCEPT
ebtables -A INPUT --log-level info --log-ip --log-prefix EBFW
ebtables -A OUTPUT -p IPv4 -j ACCEPT
ebtables -A OUTPUT -p ARP -j ACCEPT
ebtables -A OUTPUT --log-level info --log-ip --log-arp --log-prefix EBFW
-j DROP
#drop DHCP broadcast
ebtables -A FORWARD -d ff:ff:ff:ff:ff:ff/ff:ff:ff:ff:ff:ff -p IPv4
--ip-prot udp --ip-dport 67:68 --log-level info --log-ip --log-prefix
EBFWbc -j DROP
ebtables -A FORWARD -p ipv4 --ip-proto tcp --ip-destination-port 67:68
--log-level info --log-ip --log-prefix EBFWtcp -j DROP
ebtables -A FORWARD -p ipv4 --ip-proto udp --ip-destination-port 67:68
--log-level info --log-ip --log-prefix EBFWudp -j DROP
# Let the rest of the Packets through
ebtables -A FORWARD -p IPv4 -j ACCEPT
ebtables -A FORWARD -p ARP -j ACCEPT
But this is what I see in the logfile on the remote side..
Sep 12 19:05:09 firewall kernel: EBFWbc IN=tap0 OUT=eth1 MAC source =
00:10:dc:e3:2e:64 MAC dest = ff:ff:ff:ff:ff:ff proto = 0x0800 IP
SRC=192.168.8.22 IP DST=255.255.255.255, IP tos=0x00, IP proto=17 SPT=68
DPT=67
Sep 12 19:05:09 firewall dhcpd: DHCPINFORM from 192.168.8.22 via br0
Sep 12 19:05:09 firewall dhcpd: DHCPACK to 192.168.8.22
(00:10:dc:e3:2e:64) via br0
Sep 12 19:14:37 firewall kernel: EBFWbc IN=tap0 OUT=eth1 MAC source =
00:13:72:2b:37:47 MAC dest = ff:ff:ff:ff:ff:ff proto = 0x0800 IP
SRC=192.168.8.24 IP DST=255.255.255.255, IP tos=0x00, IP proto=17 SPT=68
DPT=67
Sep 12 19:14:37 firewall dhcpd: DHCPREQUEST for 192.168.8.60 from
00:13:72:2b:37:47 (ws02) via br0
Sep 12 19:14:37 firewall dhcpd: DHCPACK on 192.168.8.60 to
00:13:72:2b:37:47 (ws02) via br0
ebtables seems to want to block the packets, but dhcpd gets them anyway
and responds. Note that on both sides of the connection have dhcpd
running on br0, on with different ranges. (both eth1 and tap0 are
bridged to br0)
So why are the packets not blocked from dhcpd? What am I missing?
Thanks for any help.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 251 bytes --]
next reply other threads:[~2009-09-12 20:19 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-12 20:19 Eddie [this message]
2009-09-13 19:52 ` Blocking DHCP with ebtables Pascal Hambourg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4AAC026A.9000208@softhome.net \
--to=eddies@softhome.net \
--cc=netfilter@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.