% Fixing the Advanced DMZ in the Bell Home Hub 3000 router % Ian! D. Allen -- -- [www.idallen.com] % Updated: ``{=html} ``{=html} Advanced DMZ vs. PPPoE Pass-Through =================================== You can get a public IP address for a machine on your internal network using either the **Advanced DMZ** feature of the Bell Home Hub 3000 router, or by using **PPPoE Pass-Through**: - Turning on **Advanced DMZ** in the Hub configures *one* machine on your internal network, selected by MAC address, with the public IP address of your router. **Advanced DMZ** routing is misconfigured by Bell, so it might not work unless you follow the fixes proposed in this document. - Using **PPPoE Pass-Through**, you can give *one or more* machines on your internal network public IP addresses. The Hub automatically recognizes and does this for you; no configuration is needed, and it works in parallel with **Advanced DMZ** so you can do both (though probably not on the same machine but I haven't tried that yet). **Advanced DMZ** only works for one machine on your internal network, may require fixing the misconfigured Bell Hub routing, and will stop working if your DMZ machine reboots. **PPPoE Pass-Through** works for every machine, and you control the routing. Both appear to be approximately equal in speed for downloading and uploading. **PPPoE Pass-Through** can be used on a machine *in addition* to DHCP on your local network: any machine can have both its Hub-assigned local DHCP address as well as a public IP address assigned to the pass-through PPPoE session. (You need to configure your machine routing properly to be multi-homed to handle two IP addresses.) This document covers only how to make **Advanced DMZ** work. As explained below, I recommend using **PPPoE Pass-Through**, not the broken **Advanced DMZ**. Using the Hub Advanced DMZ ========================== I have a fully working **Bell Home Hub 3000 Advanced DMZ** configured on one interface of a multi-homed home workstation. I have access to the Hub's private LAN out the same interface card as the WAN. I can ping (ICMP) both inbound and outbound. Traceroute works. Clients on the Hub LAN can access the DMZ using the Hub WAN address, and the DMZ can access Hub LAN clients using LAN IP addresses. The DMZ interface functions exactly as if it were directly on the open Internet, using the WAN address of the Hub as its IP address. The other functions of the Hub are untouched. Advanced DMZ works with one single interface -------------------------------------------- You can probably get the **Advanced DMZ** working out-of-the box with no tinkering if you assign the **Advanced DMZ** to a machine that has only one network interface connection, where all the packets come in and go out the same network interface. (Not a router!) For the **Advanced DMZ** to work out-of-the-box with no modification, you must assign the DMZ to a single laptop or desktop machine containing no other network cards. (All the network packets have to enter and leave using the same assigned default route.) Then the **Advanced DMZ** might work to a single machine with a single network interface (not a router). Advanced DMZ does not work with multiple interfaces --------------------------------------------------- You probably can't assign the **Advanced DMZ** to a router or any multi-homed machine containing multiple network interfaces without fixing the routing assigned by Bell. The DMZ won't work because Bell misconfigures the routing, and you need proper routing on a multi-interface machine such as a router. (A single-homed DMZ machine doesn't care, because all the routing goes out the same single interface, even if it's misconfigured.) Below is the tinkering you need to make the **Advanced DMZ** work when assigned to a multi-interface machine, such as a router. You must do these changes if you want the **Advanced DMZ** to work with a router. Bell misconfigures the DMZ interface ==================================== My Hub is version SG482220DC. Using my **Bell Home Hub 3000 Advanced DMZ**, when Bell assigns the WAN IP to my chosen DMZ machine's network card using DHCP, Bell gives my DMZ machine this nonsense DHCP configuration: lease { interface "eth3"; fixed-address 74.15.XXX.XXX; # XXX edit for privacy option subnet-mask 128.0.0.0; option routers 10.11.0.49; option dhcp-lease-time 86400; option dhcp-message-type 5; option domain-name-servers 67.69.235.1,207.164.234.193; option dhcp-server-identifier 192.168.2.1; renew 6 2022/12/17 17:02:38; rebind 0 2022/12/18 03:32:46; expire 0 2022/12/18 06:32:46; } There is so much wrong with this. Note that there are no less than *four* network routes needed to make this work (for IPs 74.15.XXX.XXX, 10.11.0.49, 192.168.2.1, 67.69.235.1, and 207.164.234.193), though some can be combined into one "default" route. Wrong DHCP server ----------------- First, the `dhcp-server-identifier` IP is wrong for my Hub; it's the default LAN IP address of the Bell Hub if you don't change it. I changed my Hub to 192.168.2.254. Bell doesn't make this `dhcp-server-identifier` address change to match; it's still the default. Wrong. DHCP renewal requests sent from my DMZ back to this non-existent 192.168.2.1 address fail until the lease expires and my DHCP client (`dhclient`) gives up sending **DHCPREQUEST** to the non-existent address 192.168.2.1 and tries a broadcast **DHCPDISCOVER** that works. (And again the reply from the Bell Hub contains the wrong 192.168.2.1 `dhcp-server-identifier`, and the process repeats when that lease expires.) > If your DHCP client only tries the **DHCPREQUEST** to the non-existent > 192.168.2.1 address and never gives up to switch to the more general > **DHCPDISCOVER**, then after a day or so you'll lose your DHCP WAN > assignment and your WAN connection will stop working. > > If you can, tell the DHCP client on your DMZ machine to do **DHCPREQUEST** > to the correct Hub LAN IP so that your WAN IP renews properly and doesn't > wait for the **DHCPDISCOVER** to happen. > > Or, don't change your Hub LAN IP from the default 192.168.2.1. Wrong network subnmask ---------------------- Next, look at the IP address Bell creates on the DMZ with that nonsense 128.0.0.0 subnet-mask: eth3 inet 74.15.XXX.XXX/1 brd 127.255.255.255 I've never seen a /1 CIDR in use. A "whois" on that network block shows that the largest it should be is /14. The /1 is wrong. You have to fix the network mask for your assigned IP address on your DMZ machine, and remove any nonsense route that follows from that invalid network mask. Replace the bad route Bell gives you with the correct CIDR route for for your WAN address (my route is 74.12.0.0/14). Missing route to the gateway ---------------------------- Depending on your DHCP client, you may be missing an explicit route to the gateway IP out the WAN interface. Add the missing route that sends traffic to the Hub gateway IP out the WAN interface (10.11.0.49 and eth3 in my case). > This might fail if your DMZ machine notices that that the WAN interface has > been assigned a public WAN IP and refuses to pass private LAN addresses out > to the public network. You'll have to allow that private 10.11.0.49 address > to go out the WAN interface. Missing route for Hub LAN network --------------------------------- Note that the DHCP server address is a local LAN address: 192.168.2.1. You need to route traffic to your local LAN out the WAN interface. Add the missing route that also sends the LAN network (mine is the default 192.168.2.0/24) out the WAN interface via the gateway IP 10.11.0.49. (It is crucial that you send it *via* the gateway IP.) You need this route to reach the `dhcp-server-identifier` IP address (Bell says this is 192.168.2.1 but on my network it should be 192.168.2.254) as well as all the machines on your LAN. > Again, this might fail if your DMZ machine notices that the WAN interface > has been assigned a public WAN IP and refuses to pass private LAN addresses > out to the public network. You'll have to allow your private LAN > 192.168.2/24 addresses to go out the WAN interface via the 10.11.0.49 > gateway. Incorrect MTU confusion ----------------------- The MTU of the DMZ interface sometimes identifies itself as a full 1500, not the 1492 I would have expected for a PPPoE session: $ traceroute -4 -m 2 -n -i eth3 --mtu 1.1.1.1 traceroute to 1.1.1.1 (1.1.1.1), 2 hops max, 65000 byte packets 1 192.168.2.254 3.233 ms F=1500 1.187 ms 1.011 ms 2 * * * But if you actually try a "don't fragment" **traceroute** with any size over 1492, it fails: # traceroute -4 -n -i eth3 -F 1.1.1.1 1493 traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 1493 byte packets 1 192.168.2.254 16.938 ms 16.863 ms 16.836 ms 2 * * * [...] 29 * * * 30 * * * Apparently the Hub isn't passing back the ICMP "fragmentation needed" packets. Using a packet size of 1492 works fine, so for best results you should over-ride the 1500 MTU on your DMZ to be 1492. Missing routes for Bell DNS servers ----------------------------------- Optionally, if you use the Bell DNS servers, assign routes that send the two Bell `domain-name-servers` IP addresses out the WAN interface. > You can just use the Hub LAN IP address (the default is 192.168.2.1) as > your DNS server and the Hub will use the Bell servers without you needing > to add routes for them. It works, until you reboot ========================== The above reconfigurations fix all the damage done by the misconfigured Bell DHCP. After making the above routing changes on my DMZ machine, the **Bell Home Hub 3000 Advanced DMZ** works. > If you have a multi-homed DMZ machine, you may need to add the necessary > rules to your routing to make incoming packets go out the same interface > that they came in, just as you would do for any multi-home machine. > (Hopefully your router already does this.) I have access to my Hub private LAN out the same interface card as the WAN. I can ping (ICMP) both inbound and outbound on LAN and WAN. Traceroute works. Clients on my LAN can access the DMZ using the WAN address 74.15.XXX.XXX, and the DMZ can access LAN clients using LAN IP addresses. > Some trickery happens inside the Bell Hub when your DMZ machine accesses a > LAN machine using the private LAN IP. The packet from the DMZ (source > address 74.15.XXX.XXX) goes to the gateway IP 10.11.0.49 inside the Hub and > the Hub does SNAT to change the source address from the 74.15.XXX.XXX WAN > address to an anonymous 169.1.1.1 source address when passing it to your > LAN client. The return packet from the LAN client returns to the Hub > gateway and the 169.1.1.1 destination address is replaced by the > 74.15.XXX.XXX destination address (un-SNAT) and the packet is sent to your > DMZ machine. So your client machines will never see any connections from > the DMZ WAN IP address. You really notice the multiple Bell DHCP misconfigurations if you have a multi-homed **Advanced DMZ** host, such as a router, where not everything goes in and out the same network card. Reboot or network drop disconnects the DMZ ------------------------------------------ If you have your DMZ machine directly wired into your Hub with no switch in between, then when you reboot either the Hub or your DMZ machine, you will lose the working DMZ. After the DMZ reboot, from the DMZ machine you will find you can no longer ping the gateway IP 10.11.0.49, which makes the DMZ machine useless. Disconnecting the Ethernet cable from the Hub has the same effect; the DMZ machine is cut off from the Hub and won't reconnect when the cable is reconnected. After carrier is interrupted on the DMZ port (when the Hub loses carrier), reconnecting the cable doesn't work. After loss of carrier, the Hub refuses to acknowledge any incoming traffic to the gateway IP (10.11.0.49). If you insert a switch between the Hub and the DMZ machine, then you can disconnect the DMZ network cable or reboot the DMZ machine and the Hub won't see carrier drop because it's connected to the switch, so the DMZ will still work. If you have a power outage and lose power to your switch, the problem will recur and you will have to use the web interface to re-establish the DMZ, as explained next. If you don't use a switch, or if your switch loses power and the DMZ stops working, you can use the Hub web interface (logging in via a separate client machine on your LAN, because the DMZ machine won't work) to turn off, save, and then turn on and save the **Advanced DMZ** check-mark to get the DMZ working again (until the next loss of carrier). > This fault makes the **Advanced DMZ** unsuitable for unattended operation, > since a power outage will render the DMZ non-functional until you can use > the web interface to manually re-enable it. Use **PPPoE Pass-Through** > instead. Shell script to fix everything ============================== Below is the shell script I use to fix the addressing and routing of my multi-homed Linux machine any time it gets a new IP address on eth3 (via a script under `/etc/dhcp/dhclient-exit-hooks.d/`). The script includes most of the above fixes plus some added tweaks to arrange that incoming packets from the Hub LAN go out the same interface that they came in on (which isn't needed if you have only one network card in your DMZ machine). #!/bin/sh -u # $0 interface # Call this script from a script under /etc/dhcp/dhclient-exit-hooks.d/ # when DHCP is used on your WAN interface and 'reason' is 'BOUND'. # You'll need to tweak this for the name of your interface card. # -Ian! D. Allen - idallen@idallen.ca - www.idallen.com if=${1-eth3} table=$(( ${if##*[a-z]} + 1 )) # add one to the ethN number metric=${IF_METRIC-400} router=${new_routers-10.11.0.49} ip=${new_ip_address-74.15.XXX.XXX} ip route replace $router dev $if proto dhcp scope link metric $metric ip route replace $router dev $if proto dhcp scope link table $table ip route replace default via $router dev $if proto dhcp metric $metric ip route replace default via $router dev $if proto dhcp table $table ip route replace 192.168.2.0/24 via $router dev $if proto dhcp metric $metric ip rule add from $ip lookup $table prio 10${table}0 ip link set "$if" mtu 1492 The above doesn't fix the bad /1 subnet mask; I do that by setting the correct /14 mask inside a script under `dhclient-exit-hooks.d` so that the correct mask is used when the routing is done and it doesn't need fixing. The resulting network configuration for my dual-homed DMZ machine looks like this (edited to mask my actual IP address with XXX.XXX): ----- IP inet Addresses ---------------------------------- eth0 inet 192.168.9.250/24 brd 192.168.9.255 scope global eth0 mtu 1500 eth3 inet 74.15.XXX.XXX/14 brd 74.15.255.255 scope global dynamic eth3 mtu 1492 lo inet 127.0.0.1/8 scope host lo mtu 65536 ----- IP Rules ---------------------------------- 0: from all lookup local 1010: from 192.168.9.250 lookup 1 1040: from 74.15.XXX.XXX lookup 4 32766: from all lookup main ----- Table 1 ---------------------------------- default via 192.168.9.1 dev eth0 src 192.168.9.250 192.168.9.0/24 dev eth0 scope link src 192.168.9.250 ----- Table 4 ---------------------------------- default via 10.11.0.49 dev eth3 proto dhcp 10.11.0.49 dev eth3 proto dhcp scope link ----- Table main ---------------------------------- default via 192.168.9.1 dev eth0 src 192.168.9.250 metric 100 default via 10.11.0.49 dev eth3 proto dhcp metric 400 10.11.0.49 dev eth3 proto dhcp scope link metric 400 74.12.0.0/14 dev eth3 proto kernel scope link src 74.15.XXX.XXX 169.254.0.0/16 dev eth3 scope link metric 1000 192.168.2.0/24 via 10.11.0.49 dev eth3 proto dhcp metric 400 192.168.9.0/24 dev eth0 proto kernel scope link src 192.168.9.250 It works. Links to this article ===================== - - - - -- | Ian! D. Allen, BA-Psych, MMath-CompSci idallen@idallen.ca Ottawa CANADA | Home: www.idallen.com Contact Improvisation Dance: www.contactimprov.ca | Former college professor of Free/Libre GNU+Linux @ teaching.idallen.com | Improve democracy www.fairvote.ca and defend digital freedom www.eff.org [Plain Text] -- plain text version of this page in [Pandoc Markdown] format [www.idallen.com]: http://www.idallen.com/ [Plain Text]: bell_home_hub_3000_advanced_DMZ.txt [Pandoc Markdown]: https://pandoc.org/