Multiple WAN interfaces and Dynamic DNS

Forums Network Management ZeroShell Multiple WAN interfaces and Dynamic DNS

  • This topic is empty.
Viewing 15 posts - 1 through 15 (of 23 total)
  • Author
  • #42457

    How can I setup a Dynamic DNS name for each of my WAN Connections. One is a cable modem (DHCP) and the other is DSL (PPPoE).

    So far I’ve determined that the DHCP connection is the one using the Dynamic DNS, but I see no way to assign another set of definition to the PPPoE connection.


    The solution I have found for that matter is to use 2 PCs in my network with the inadyn dyndns update client. On Netbalancer I have configured these 2 PCs to use a different gateway so they update their dyndns account from a different connection.


    That’s indeed a smart solution. Are you routing all traffic from these internal PCs to a specific gateway or are you performing some selection?

    I have resorted to a different solution as I have yet another problem. I’m using one DSL (PPPoE) and one Cable Modem (DHCP) connections. When I use the net balancer, for some reason the Cable Modem (DHCP) does not play well.

    My guess is that ZS is not using the default gateway provided by DHCP in the netbalance, therefore the “path” is there, but with a router assigned. So any packed sent over the cable modem path goes nowhere.

    So I’ve included a small router between the cable modem and ZS. Now ZS sees the Cable modem path as a fixed IP and net balance works fine with the DSL (PPPoE). A side effect is that the router is also handling the Dynamic DNS for the Cable modem connection.

    ZS needs to include proper handling for modems that work with DHCP. There are Cable and DSL modem that work that way. The are 3 areas that need to be addressed:

    a) The way netbalance see the connection (the gateway is dynamic)
    b) There can be a Dynamic DNS assigned to it. In fact this will be true also for multiple PPPoE connections
    c) Like PPPoE, there need to be a “Use this a the default gateway” setting, so that it will be handled properly during changes.


    If you have a problem with DHCP and gateway changing, you can set the interface in the netbalancer instead of an IP. This works in cases you have ppp interfaces with no standard IP-gateway.


    You are correct. The PPPoE interfaces, without a fixed gateway works fine. The problem is with ethernet interfaces that get their address from DHCP, and thus do not have a fixed gateway.


    Could you post here the routing table with both connections working?


    These are the 2 scenarios:

    On the left size, the case that ZeroShell fail to support with Netbalance. My guess is that SZ expect Ethernet adapters to be specified to netbalance with a gateway, and will not pick the DHCP assigned one. The routing case for this case is:

    Also, for this scenario, the Dynamic DNS works only for the PPPoE interface, as it will not work for 2 interfaces nor for DHCP based interfaces.

    On the right size of the first image is the scenario that I had to resort to. I’ve added an intermediate router to make the ethernet interface for ZS a fixed IP, as well as to handle the Dynamic DNS for the cable modem side.
    The routing table for this case is:


    Something seems to be wrong in your configuration, as in both cases the IP address of the ETH01 is the same, which doesn’t make sense. On the first case you should have a public IP assigned by your cable internet provider. On the second case this public IP is assigned on your border router. Can you verify that your cable provider is indeed sending DHCP?

    tcpdump -i ETH01 -w /Database/test.pcap

    Use this command to capture the traffic of ETH01. It quits with Ctrl-c. Make sure you use it when you power up the cable modem so that the DHCP packets are captured.Transfer it with ftp to your pc and upload it here.


    my bad. I posted the wrong image (I will have it replaced), but on that particular case interface ETH01 (second line) has the address:

    And yes, I’m 100% sure it’s DHCP (been using it for years!).


    Still I don’t understand why you don’t have on your routing table the default gateway announced by your provider. He must be sending it to you during the DHCP handshake process otherwise your modem wouldn’t work. COuld you capture the packets in the way that I described above to see what is wrong?


    It’s fuzzy because there is a bug in ZS when turning the netbalancer on with a DHCP Ethernet address.
    Let me try to explain. This is the routing info as I turn the interfaces on, then turn nb on.

    1) No interfaces up (except for the internal one):

    root@rhea root> ip route show dev VPN99 proto kernel scope link src dev ETH00 proto kernel scope link src

    2) After PPPoE is up. PPPoE is defined not to be the default route:

    root@rhea root> ip route show dev ppp0 proto kernel scope link src dev VPN99 proto kernel scope link src dev ETH00 proto kernel scope link src

    As expected, no default route was defined.

    3) After I bring the ETH01 (DHCP) up:

    root@rhea root> ip route show dev ppp0 proto kernel scope link src dev VPN99 proto kernel scope link src dev ETH00 proto kernel scope link src dev ETH01 proto kernel scope link src
    default via dev ETH01

    As you can see, the DHCP supplied default gateway is indeed set.

    4) Now, time to turn netbalancer on.

    root@rhea root> ip ro sh dev ppp0 proto kernel scope link src dev VPN99 proto kernel scope link src dev ETH00 proto kernel scope link src dev ETH01 proto kernel scope link src
    nexthop dev ETH01 weight 6
    nexthop dev ppp0 weight 8

    Aha! See that the nexthop line for ETH01 is missing the default gw. As soon as the Failover
    code runs, there is no way to send a ping packet thru the ETH01 path, thus the interace is
    marked as in “Fault” and the routing table reverts to:

    root@rhea root> ip route show dev ppp0 proto kernel scope link src dev VPN99 proto kernel scope link src dev ETH00 proto kernel scope link src dev ETH01 proto kernel scope link src
    default dev ppp0 realm 102

    I have been sifting thru the myriad of ZS scripts trying to figure out what’s
    going on and if a simple fix is possible.

    My undestanding is that the correct output for the “ip show route” when the nb is up should
    change the “nexthop” line for ETH01 to read:

    nexthop dev ETH01 weight 6

    I’ve done several tests and it points out that SZ is not properly handling ethernet interaces with
    DHCP addresses when part of a netbalance scheme. It seems that it expect the ethernet interface to have
    a default gw defined in the neebalance settings, but in this case it has only the name of the interface.
    The result is that the routing table become incorrect and the interface is marked as being at fault.

    I can try help fixing the scripts if I can get some clue of the sequence executed when the netbalance is
    turned on.


    The scripts responsible for the NetBalancer of ZS are located in


    Have a look on them, I’ll try to reproduce the error in my testbed as well.


    As I said, there is a myriad of scripts there.

    But here is what I have found, looking at 2 scripts that deal with the routing (routeupd and nb_setnexthop).

    The whole logic in SZ, as I predicted, assumes the following rules, based on the nb gateways configuration:

    a) A gateway is valid if either the INTERFACE or IP (address of nexthop gw) is defined.

    b) If the gw IP is defined, then it’s used for the routing

    c) If the gw IP is not defined, then the INTERFACE will be used

    This is the logic all over. This works fine for Point-to-Point interfaces, like PPPoE (as well as any other P-t-P interaces) but will NEVER work for broadcast interfaces like ETHERNET. Point-to-Point do not require a gw address cause the gateway is always at the other end of the line. But for broadcast interfaces, unless the gw address is known, the route will not work.

    It tried hacking these 2 scripts to check for a DHCP supplied default gateway in case the information was not there (that is the nb gateway definition includes the interface and it has DHCP client services enabled).

    The code to pick the DHCP default gateway is kinda simple, thanks for the fact that there is a lease file per interface, so just grep for the proper like and “tac” + “head” to get the last entry then awk to extract the ip address. Works fine (I’ve wrote an external script for that).

    But there seems to be a lot more involved than these 2 scripts. Still looking, but it’s kinda hard without a good understanding of how all those scripts interact (and there is a lot of interaction there).


    Ok, I’m currently testing some mods that seems to get this (NB with DHCP) working.

    I’ve determined the “issue” to be the way the default gateway IP address is determined for each NB gateway. Basically the code retrieves the value that is stored for each NB gateway condiguration. The issue is that in the case of a DHCP ethernet link, this will blank.

    So I’ve opted for creating a new script that will CORRECTLY retrieve the gateway address. The logic is as follows:

    a) Retrieve the gateway IP address from the configuration
    b) If the IP address is “blank”, it means a dynamic interface (such as PPPoE, DHCP, etc).
    c) For a dynamic interface, if it’s a DHCP interface, retrieve the gateway IP from the leases file

    This will give the correct IP for the 3 possible cases:

    1) It was defined in the NB gateway settings (typically for a fixed address Ethernet)
    2) Only the Interface was defined and DHCP is NOT in use (typically PPPoE)
    3) Only the Interface was defined and DHCP IS in use (the case in question here)

    The code I’ve written to implement this is:


    . /etc/kerbynet.conf
    IP=`cat $GW/IP 2>/dev/null`
    if [ -z "$IP" ] ; then
    INTERFACE=`cat $GW/Interface 2>/dev/null`
    if [ -n "$INTERFACE" ] ; then
    STATUS=`cat $DHCP/Status 2>/dev/null`
    if [ "$STATUS" = Enabled ]; then
    IP=`cat $DHCP/leases 2>/dev/null | grep routers | awk 'END{sub(/;/,"") ; print $3}'`

    Then it was a matter of checking several scripts for any place to use the above code. The idea is to look for place where the IP is retrieved and if it is blank, a point-to-point interface is assume. By changing (actually making it more complete) the way the IP address is retrieved it allows the “empty” IP test to work, as the Ethernet with DHCP will now have a default gateway IP address and it will behave as a normal Ethernet with a default gateway.

    I’ve found this test to exist on: nb_setnexthop, routeupd and failoverd (2 times) scripts.

    The change was:

    IP=`cat $GW/IP 2>/dev/null`


    IP=`$SCRIPTS/nb_getgwip $G`

    (for failoverd the variable is not “IP”, but “cIP” and “W”)

    I’ve done some initial testing and I can enable/disable the NB, as well as bring either interface to faul (one is PPPoE and the other is the DHCP). I will keep this running for a while and see how it behaves. I will post any relevant finding.


    To wrapup, I have written a small script to properly handle a per interface DynDNS control. No need to resort to tagging to get the packet out thru the proper interface.

    Make the script available and start it from the “post” boot script as:

    dyndns interface hostname authentication waitinterval


    dyndns ETH01 joedoe:lame 120

    Do not forget to place the script in the background (& at the end). To make it safer, I’m also adding a cron based script to run every 1 hour to

    killall -w dyndns

    and then repeat the whole startup process. This is manual configuration, but work fine.

    The original DDNS script of SZ is not very “smart”. As I understant it, it just ignores the interface concept (it will take the
    route that is available) and the IP address that will be registered will be the one of the “lucky” interface.

    . /etc/kerbynet.conf


    while true ; do
    sleep $INTERVAL
    NEW_IP=`ip addr show $INTERFACE 2> /dev/null | grep inet | awk '{ sub(///, " ") ; print $2 }'`
    if [ -n "$NEW_IP" -a "$NEW_IP" != "$LAST_IP" ]; then
    DNS_IP=`host $HOSTNAME 2> /dev/null | cut -d" " -f4`
    if [ "$NEW_IP" != "$DNS_IP" ]; then
    logger -t DDNS "DynDNS change required for internet $INTERFACE ($HOSTNAME)"
    logger -t DDNS "==> new ip: $NEW_IP - old ip: $DNS_IP"
    if wget -q -t 3 -w 20 if wget -t 3 -w 20 -o "$ERROR" -O "$RESULT" "http://${AUTH}${HOSTNAME}&myip=${NEW_IP}&wildcard=NOCHG&mx=NOCHG&backmx=NOCHG"; then
    logger -t DDNS "==> `cat $RESULT`"
    logger -t DDNS "ERROR:"
    grep -v " => " "$ERROR" | logger -t DDNS
    sleep 60
Viewing 15 posts - 1 through 15 (of 23 total)
  • You must be logged in to reply to this topic.