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.
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.
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 interfacesIndex
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.
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:
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.
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.
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).
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.
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.
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.
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.
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.
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
