What's new

DHCP requests and responses being allowed across the XT8 WAN port?

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

e-horace

New Around Here
I have a rather puzzling problem. I have two XT8s set up in the following configuration:
  • A Virgin Media SuperHub 3 acting as cable router, DHCP enabled but WiFi disabled.
  • An outer XT8 connected to the VM Hub through LAN, DHCP disabled but WiFi enabled (effectively offloading the WiFi function of the underpowered SuperHub)
  • An inner XT8 with its WAN connected to OUTER's LAN, with WiFi and DHCP enabled (keeping the inner LAN protected from devices on the outer LAN).
Inner network
^
|
v
XT8-INNER:WAN <---> LAN(eth1):XT8-Outer:LAN(eth2) <---> Broadband Hub <---> Internet
^
|
v
Outer network
- I hope this makes sense.

The problem I'm having is that the inner XT8 seems to be allowing DHCP requests and responses through the WAN port from either side. The effect of this is that when a DHCP request is made, the DHCP servers on both the SuperHub and INNER will respond. This can result in clients on one network receiving addresses from the other network, causing confusion as to which address a client receives and more than a little confusion with routing.

I would have thought that the WAN firewall configuration ought to default to preventing DHCP packets passing across the boundary but the rules don't seem to include anything to match them:
iptables -S -v| egrep -i '67|68'
produces nothing but a bunch of unrelated DNS rules.

I'm predominantly using the web interface to manage them but I do have SSH enabled so I'm able to run lower level command directly. I've tried a bunch of iptables and ebtables rules (new to me) to drop UDP port 67 and 68 packets crossing the INNER WAN interface -
On INNER:
iptables -A INPUT -i eth0 -p udp --destination-port 68 --source-port 67 -j DROP
iptables -A INPUT -i eth0 -p udp --destination-port 67 --source-port 68 -j DROP
iptables -A OUTPUT -o eth0 -p udp --destination-port 68 --source-port 67 -j DROP
iptables -A OUTPUT -o eth0 -p udp --destination-port 67 --source-port 68 -j DROP
That didn't work.

Also on INNER:
ebtables -A FORWARD -i eth0 -d ff:ff:ff:ff:ff:ff/ff:ff:ff:ff:ff:ff -p IPv4 --ip-prot udp --ip-dport 67:68 -j DROP
ebtables -A FORWARD -o eth0 -d ff:ff:ff:ff:ff:ff/ff:ff:ff:ff:ff:ff -p IPv4 --ip-prot udp --ip-dport 67:68 -j DROP
Didn't work.

So I tried:
ebtables -A INPUT -i eth0 -d ff:ff:ff:ff:ff:ff/ff:ff:ff:ff:ff:ff -p IPv4 --ip-prot udp --ip-dport 67:68 -j DROP
ebtables -A OUTPUT -o eth0 -d ff:ff:ff:ff:ff:ff/ff:ff:ff:ff:ff:ff -p IPv4 --ip-prot udp --ip-dport 67:68 -j DROP
- Nope.

INNER's WAN is connected to eth1 of OUTER so I tried these rather specific rules:
ebtables -A FORWARD -i eth1 -d ff:ff:ff:ff:ff:ff/ff:ff:ff:ff:ff:ff -p IPv4 --ip-prot udp --ip-dport 67:68 -j DROP
ebtables -A FORWARD -o eth1 -d ff:ff:ff:ff:ff:ff/ff:ff:ff:ff:ff:ff -p IPv4 --ip-prot udp --ip-dport 67:68 -j DROP

and when that didn't work, I tried this:
ebtables -A INPUT -i eth1 -d ff:ff:ff:ff:ff:ff/ff:ff:ff:ff:ff:ff -p IPv4 --ip-prot udp --ip-dport 67:68 -j DROP
ebtables -A OUTPUT -o eth1 -d ff:ff:ff:ff:ff:ff/ff:ff:ff:ff:ff:ff -p IPv4 --ip-prot udp --ip-dport 67:68 -j DROP
Again, no joy.

(As an aside, not having tcpdump on the XT8s makes it a little harder to investigate but I couldn't find a port for these boxes.)

Unsurprisingly I couldn't find any option within Admin interface along the lines of "Did you want to enable forwarding DHCP requests and responses over WAN port?".

Any ideas? Many thanks.
 
Are you sure the the inner XT8 is configured as a router and not an access point or AiMesh node?

What does the output of iptables-save on the inner XT8 look like?
 
Hi Colin,
yes, definitely set to router mode:

1635707660986.png

Here is the output from iptables-save:
Code:
# Generated by iptables-save v1.4.12.2 on Tue May 15 21:46:39 2018
*raw
:PREROUTING ACCEPT [19353076:3330536377]
:OUTPUT ACCEPT [15324380:2835391925]
COMMIT
# Completed on Tue May 15 21:46:39 2018
# Generated by iptables-save v1.4.12.2 on Tue May 15 21:46:39 2018
*nat
:PREROUTING ACCEPT [586678:156561398]
:INPUT ACCEPT [150680:13167143]
:OUTPUT ACCEPT [130327:10208201]
:POSTROUTING ACCEPT [125001:9632050]
:LOCALSRV - [0:0]
:PCREDIRECT - [0:0]
:VSERVER - [0:0]
:VUPNP - [0:0]
-A PREROUTING -d 192.168.1.201/32 -j VSERVER
-A POSTROUTING ! -s 192.168.1.201/32 -o eth0 -j MASQUERADE
-A POSTROUTING -s 10.0.0.0/24 -d 10.0.0.0/24 -o br0 -j MASQUERADE
-A VSERVER -s 192.168.1.22/32 -p tcp -m tcp --dport 22 -j DNAT --to-destination 10.0.0.12:22
-A VSERVER -j VUPNP
COMMIT
# Completed on Tue May 15 21:46:39 2018
# Generated by iptables-save v1.4.12.2 on Tue May 15 21:46:39 2018
*mangle
:PREROUTING ACCEPT [3943874:1423412698]
:INPUT ACCEPT [1152805:279246600]
:FORWARD ACCEPT [1172934:209224320]
:OUTPUT ACCEPT [1930483:1076569886]
:POSTROUTING ACCEPT [3112955:1289582044]
COMMIT
# Completed on Tue May 15 21:46:39 2018
# Generated by iptables-save v1.4.12.2 on Tue May 15 21:46:39 2018
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [659111:527243046]
:ACCESS_RESTRICTION - [0:0]
:FUPNP - [0:0]
:ICAccept - [0:0]
:ICDrop - [0:0]
:INPUT_ICMP - [0:0]
:INPUT_PING - [0:0]
:OUTPUT_DNS - [0:0]
:OUTPUT_IP - [0:0]
:PControls - [0:0]
:PTCSRVLAN - [0:0]
:PTCSRVWAN - [0:0]
:SECURITY - [0:0]
:default_block - [0:0]
:logaccept - [0:0]
:logdrop - [0:0]
:logdrop_dns - [0:0]
:logdrop_ip - [0:0]
-A INPUT -p icmp -m icmp --icmp-type 8 -j INPUT_PING
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m state --state INVALID -j logdrop
-A INPUT ! -i br0 -j PTCSRVWAN
-A INPUT -i br0 -j PTCSRVLAN
-A INPUT -i br0 -m state --state NEW -j ACCEPT
-A INPUT -i lo -m state --state NEW -j ACCEPT
-A INPUT -p icmp -j INPUT_ICMP
-A INPUT -j logdrop
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD ! -i br0 -o eth0 -j logdrop
-A FORWARD -i br0 -o br0 -j ACCEPT
-A FORWARD -m state --state INVALID -j logdrop
-A FORWARD -i br0 -j ACCEPT
-A FORWARD -m conntrack --ctstate DNAT -j ACCEPT
-A FORWARD -j logdrop
-A OUTPUT -p udp -m udp --dport 53 -m u32 --u32 "0x0>>0x16&0x3c@0x8>>0xf&0x1=0x0" -j OUTPUT_DNS
-A OUTPUT -p tcp -m tcp --dport 53 -m u32 --u32 "0x0>>0x16&0x3c@0xc>>0x1a&0x3c@0x8>>0xf&0x1=0x0" -j OUTPUT_DNS
-A OUTPUT -j OUTPUT_IP
-A ICAccept -j ACCEPT
-A ICDrop -j logdrop
-A INPUT_ICMP -p icmp -m icmp --icmp-type 8 -j RETURN
-A INPUT_ICMP -p icmp -m icmp --icmp-type 13 -j RETURN
-A INPUT_ICMP -p icmp -j ACCEPT
-A INPUT_PING -i eth0 -p icmp -j logdrop
-A OUTPUT_DNS -m string --hex-string "|10706f697579747975696f706b6a666e6603636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|0d72666a656a6e666a6e65666a6503636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|1131306166646d617361787373736171726b03636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|0f376d667364666173646d6b676d726b03636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|0d386d617361787373736171726b03636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|0f3966646d617361787373736171726b03636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|1265666274686d6f6975796b6d6b6a6b6a677403636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|086861636b7563647403636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|076c696e77756469056633333232036e657400|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|0f6c6b6a68676664736174727975696f03636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|0b6d6e627663787a7a7a313203636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|077131313133333303746f7000|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|057371353230056633333232036e657400|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|077563746b6f6e6503636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|0e7a786376626d6e6e666a6a66777103636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|0a65756d6d6167766e627003636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_IP -d 193.201.224.0/24 -j logdrop_ip
-A OUTPUT_IP -d 51.15.120.245/32 -j logdrop_ip
-A OUTPUT_IP -d 45.33.73.134/32 -j logdrop_ip
-A OUTPUT_IP -d 190.115.18.28/32 -j logdrop_ip
-A OUTPUT_IP -d 51.159.52.250/32 -j logdrop_ip
-A OUTPUT_IP -d 190.115.18.86/32 -j logdrop_ip
-A PControls -j logdrop
-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m limit --limit 1/sec -j RETURN
-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j logdrop
-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -m limit --limit 1/sec -j RETURN
-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -j logdrop
-A SECURITY -p icmp -m icmp --icmp-type 8 -m limit --limit 1/sec -j RETURN
-A SECURITY -p icmp -m icmp --icmp-type 8 -j logdrop
-A SECURITY -j RETURN
-A logaccept -m state --state NEW -j LOG --log-prefix "ACCEPT " --log-tcp-sequence --log-tcp-options --log-ip-options
-A logaccept -j ACCEPT
-A logdrop -m state --state NEW -j LOG --log-prefix "DROP " --log-tcp-sequence --log-tcp-options --log-ip-options
-A logdrop -j DROP
-A logdrop_dns -j LOG --log-prefix "DROP_DNS " --log-tcp-sequence --log-tcp-options --log-ip-options
-A logdrop_dns -j DROP
-A logdrop_ip -j LOG --log-prefix "DROP_IP " --log-tcp-sequence --log-tcp-options --log-ip-options
-A logdrop_ip -j DROP
COMMIT
 
Thanks. That looks fine.

I can't think how DHCP traffic can be moving between your two networks (192.168.1.x and 10.0.0.x). DHCP uses broadcast traffic and broadcast traffic doesn't go outside the broadcast domain (subnet).

I notice that the inner XT8 hasn't been able to set its clock. Check you have the cable plugged into its WAN socket and not the LAN socket by mistake.
 
Yes, I noticed the clock disparity when I copied the iptables output. That is weird. There seems to be something going on with the resolver. I've replaced the NTP server's DNS name with an IP and will see if that fixes that. I can't see how that would account for the DHCP passthrough. Out of interest, do you have an XT8 or equivalent and does it include rules, explicit or implicit, that would drop or reject DHCP traffic across the boundary?

It's definitely connected downward through the WAN port:
Code:
# ip a show dev eth0
12: eth0: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 3c:7c:3f:33:8b:f0 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.201/24 brd 192.168.1.255 scope global eth0
       valid_lft forever preferred_lft forever

Many thanks - Chris
 
No I don't have an XT8. I do have an RT-AX86U and RT-AC68U which have a very similar firmware but it's not identical.

I compared your iptables output with mine and they're almost identical. The main difference is that in my firmware Asus added rules to specifically allow DHCP traffic to be accepted by the router's DHCP client on the WAN interface. This was thought necessary for certain ISPs. But that's not the same as the Asus' DHCP server which should only be accessible from its LAN. In any case you don't have those rules and your router will drop any such traffic on the WAN interface by default.

Do you have anything configured under LAN > IPTV? Does the DHCP problem only manifest itself on one network or both. In other words does the rogue DHCP traffic only appear to be going in one direction?

If you post the output of cat /etc/dnsmasq.conf I can compare it to mine.
 
Last edited:
Hi Colin,
nothing configured in the IPTV tab:
1635769792774.png


Just to confirm that if I connect to INNER's wifi, the DHCP broadcast request is visible to devices on the INNER LAN:
Code:
08:27:52.311210 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 80:d2:1d:35:0e:71, length 305
08:27:52.334810 IP 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 548

and the OUTER LAN:
Code:
04:11:52.416296 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 80:d2:1d:35:0e:71, length 305
04:11:52.439938 IP 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 548

Similarly, if connecting to OUTER's wifi, the broadcasts are visible on both LANs.

Here's the contents of /etc/dnsmasq.conf:
Code:
pid-file=/var/run/dnsmasq.pid
user=nobody
bind-dynamic
interface=br0
interface=pptp*
no-dhcp-interface=pptp*
no-resolv
servers-file=/tmp/resolv.dnsmasq
no-poll
no-negcache
cache-size=1500
min-port=4096
dhcp-range=lan,10.0.0.2,10.0.0.254,255.255.255.0,86400s
dhcp-option=lan,3,10.0.0.1
dhcp-authoritative
interface=br1
dhcp-range=br1,192.168.101.2,192.168.101.254,255.255.255.0,86400s
dhcp-option=br1,3,192.168.101.1
interface=br2
dhcp-range=br2,192.168.102.2,192.168.102.254,255.255.255.0,86400s
dhcp-option=br2,3,192.168.102.1
interface=br3
dhcp-range=br3,192.168.103.2,192.168.103.254,255.255.255.0,86400s
dhcp-option=br3,3,192.168.103.1
dhcp-host=00:0F:1F:E1:6F:BA,set:00:0F:1F:E1:6F:BA,10.0.0.12
dhcp-host=80:D2:1D:35:0E:71,set:80:D2:1D:35:0E:71,10.0.0.18
dhcp-host=DC:A6:32:00:13:CF,set:DC:A6:32:00:13:CF,10.0.0.20
dhcp-host=00:0F:55:A7:B8:AC,set:00:0F:55:A7:B8:AC,10.0.0.21
dhcp-host=B8:27:EB:CF:F1:7C,set:B8:27:EB:CF:F1:7C,10.0.0.23
dhcp-host=00:0C:29:54:BF:88,set:00:0C:29:54:BF:88,10.0.0.26
dhcp-host=10:1C:0C:09:EC:A4,set:10:1C:0C:09:EC:A4,10.0.0.27
dhcp-host=00:26:9E:91:06:49,set:00:26:9E:91:06:49,10.0.0.29
dhcp-host=70:54:D2:3B:D1:15,set:70:54:D2:3B:D1:15,10.0.0.32
dhcp-host=00:0C:29:93:A6:B6,set:00:0C:29:93:A6:B6,10.0.0.33
dhcp-host=90:4C:E5:72:AC:D7,set:90:4C:E5:72:AC:D7,10.0.0.39
dhcp-host=5C:C3:07:45:72:49,set:5C:C3:07:45:72:49,10.0.0.41
dhcp-host=AC:16:2D:BE:40:9A,set:AC:16:2D:BE:40:9A,10.0.0.48
dhcp-host=C8:3A:35:B0:2C:C0,set:C8:3A:35:B0:2C:C0,10.0.0.53
dhcp-host=00:CC:CC:00:00:01,set:00:CC:CC:00:00:01,10.0.0.54
dhcp-script=/sbin/dhcpc_lease
script-arp

Thanks - Chris
 
Sorry, I can't make any sense of what's happening.

Your dnsmasq.conf looks fine. We can see that it's only listening on it's LAN interface and not its WAN interface. So there's no way it should being giving out 10.0.0.x addresses to upstream devices.

Can you just confirm that your Hub3's subnet is actually 192.168.1.x and not 192.168.0.x (which is the Hub's default).
 
Yes, you're right - the VM Hub's dfault LAN network was 192.168.0.0/24 with 192.168.1.0/24 reserved for a guest network or somesuch. When I got the Hub 3 as a replacement for an ailing Hub2, in order to reduced the churn on some of the devices I had to force walk it over to using '.1 using Karl Jorgensen's Python scripts (https://github.com/KarlJorgensen/virgin-media-hub3).

I'm mystified why none of the iptables and ebtables commands seem to have any effect. To begin with I thought that maybe there was some factory-configured bond between the two nodes that was allowing them to honour WiFi associations for each other over the wl2.5 link or somesuch but I don't see that happening, (although tcpdump or similar would have helped eliminate that with all certainty). I suspect that my best course of action will be to update to the latest firmware and if that doesn't do it, reset to the factory defaults as well.

Thanks for your input.
 

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top