www.zeroshell.org Forum Index www.zeroshell.org
Linux Distribution for server and embedded devices
 
 SearchSearch  RegisterRegister  UsergroupsUsergroups 
 ProfileProfile  Log inLog in  Log in to check your private messagesPrivate Message 

Multiple WAN interfaces and Dynamic DNS

 
Post new topic   Reply to topic    www.zeroshell.org Forum Index -> ZeroShell
View previous topic :: View next topic  
Author Message
aviegas



Joined: 19 Jun 2010
Posts: 17

PostPosted: Wed Jun 23, 2010 6:15 pm    Post subject: Multiple WAN interfaces and Dynamic DNS Reply with quote

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.
Back to top
View user's profile Send private message
ppalias



Joined: 17 Dec 2008
Posts: 1151
Location: Athens, Greece

PostPosted: Thu Jun 24, 2010 12:36 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message Yahoo Messenger MSN Messenger
aviegas



Joined: 19 Jun 2010
Posts: 17

PostPosted: Thu Jun 24, 2010 1:32 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
ppalias



Joined: 17 Dec 2008
Posts: 1151
Location: Athens, Greece

PostPosted: Thu Jun 24, 2010 10:31 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message Yahoo Messenger MSN Messenger
aviegas



Joined: 19 Jun 2010
Posts: 17

PostPosted: Fri Jun 25, 2010 11:46 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
ppalias



Joined: 17 Dec 2008
Posts: 1151
Location: Athens, Greece

PostPosted: Fri Jun 25, 2010 9:23 pm    Post subject: Reply with quote

Could you post here the routing table with both connections working?
Back to top
View user's profile Send private message Yahoo Messenger MSN Messenger
aviegas



Joined: 19 Jun 2010
Posts: 17

PostPosted: Sat Jun 26, 2010 12:50 am    Post subject: Reply with quote

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:

Back to top
View user's profile Send private message
ppalias



Joined: 17 Dec 2008
Posts: 1151
Location: Athens, Greece

PostPosted: Sat Jun 26, 2010 8:41 am    Post subject: Reply with quote

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?
Code:
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.
Back to top
View user's profile Send private message Yahoo Messenger MSN Messenger
aviegas



Joined: 19 Jun 2010
Posts: 17

PostPosted: Sat Jun 26, 2010 12:21 pm    Post subject: Reply with quote

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

189.122.194.127/255.255.255.240

And yes, I'm 100% sure it's DHCP (been using it for years!).
Back to top
View user's profile Send private message
ppalias



Joined: 17 Dec 2008
Posts: 1151
Location: Athens, Greece

PostPosted: Sat Jun 26, 2010 3:59 pm    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message Yahoo Messenger MSN Messenger
aviegas



Joined: 19 Jun 2010
Posts: 17

PostPosted: Sat Jun 26, 2010 11:25 pm    Post subject: Reply with quote

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
192.168.250.0/24 dev VPN99 proto kernel scope link src 192.168.250.254
10.10.10.0/24 dev ETH00 proto kernel scope link src 10.10.10.254

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

root@rhea root> ip route show
200.222.117.78 dev ppp0 proto kernel scope link src 201.29.251.73
192.168.250.0/24 dev VPN99 proto kernel scope link src 192.168.250.254
10.10.10.0/24 dev ETH00 proto kernel scope link src 10.10.10.254

As expected, no default route was defined.

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

root@rhea root> ip route show
200.222.117.78 dev ppp0 proto kernel scope link src 201.29.166.4
192.168.250.0/24 dev VPN99 proto kernel scope link src 192.168.250.254
10.10.10.0/24 dev ETH00 proto kernel scope link src 10.10.10.254
189.122.192.0/20 dev ETH01 proto kernel scope link src 189.122.198.49
default via 189.122.192.1 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
200.222.117.78 dev ppp0 proto kernel scope link src 201.29.225.70
192.168.250.0/24 dev VPN99 proto kernel scope link src 192.168.250.254
10.10.10.0/24 dev ETH00 proto kernel scope link src 10.10.10.254
189.122.192.0/20 dev ETH01 proto kernel scope link src 189.122.198.49
default
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
200.222.117.78 dev ppp0 proto kernel scope link src 201.29.166.4
192.168.250.0/24 dev VPN99 proto kernel scope link src 192.168.250.254
10.10.10.0/24 dev ETH00 proto kernel scope link src 10.10.10.254
189.122.192.0/20 dev ETH01 proto kernel scope link src 189.122.198.49
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 189.122.192.1 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.
Back to top
View user's profile Send private message
ppalias



Joined: 17 Dec 2008
Posts: 1151
Location: Athens, Greece

PostPosted: Sun Jun 27, 2010 9:44 am    Post subject: Reply with quote

The scripts responsible for the NetBalancer of ZS are located in
Code:
/root/kerbynet.cgi/scripts/nb_*

Have a look on them, I'll try to reproduce the error in my testbed as well.
Back to top
View user's profile Send private message Yahoo Messenger MSN Messenger
aviegas



Joined: 19 Jun 2010
Posts: 17

PostPosted: Sun Jun 27, 2010 9:07 pm    Post subject: Reply with quote

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).
Back to top
View user's profile Send private message
aviegas



Joined: 19 Jun 2010
Posts: 17

PostPosted: Tue Jun 29, 2010 4:17 pm    Post subject: Reply with quote

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:

nb_getgwip
Code:
#!/bin/sh
. /etc/kerbynet.conf
GW="$1"
IP=`cat $GW/IP 2>/dev/null`
if [ -z "$IP" ] ; then
    INTERFACE=`cat $GW/Interface 2>/dev/null`
    if [ -n "$INTERFACE" ] ; then
        DHCP="$REGISTER/system/net/interfaces/$INTERFACE/dhclient"
        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}'`   
        fi   
    fi
fi


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:

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


to

Code:
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.
Back to top
View user's profile Send private message
aviegas



Joined: 19 Jun 2010
Posts: 17

PostPosted: Tue Jun 29, 2010 7:38 pm    Post subject: Reply with quote

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

ex:

dyndns ETH01 myhost.dnsalias.com 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.


Code:
#!/bin/sh
. /etc/kerbynet.conf
INTERFACE="$1"
HOSTNAME="$2"
AUTH="$3"
INTERVAL="$4"

ERROR="/tmp/dyndns.$INTERFACE.err"
RESULT="/tmp/dyndns.$INTERFACE.out"
LAST_IP="X"

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}@members.dyndns.org/nic/update?hostname=${HOSTNAME}&myip=${NEW_IP}&wildcard=NOCHG&mx=NOCHG&backmx=NOCHG"; then
                logger -t DDNS "==> `cat $RESULT`"
            else
                logger -t DDNS "ERROR:"
                grep -v " => " "$ERROR" | logger -t DDNS
            fi
            sleep 60
        fi
    else
        LAST_IP="$NEW_IP"
    fi
done
Back to top
View user's profile Send private message
ppalias



Joined: 17 Dec 2008
Posts: 1151
Location: Athens, Greece

PostPosted: Wed Jun 30, 2010 6:27 am    Post subject: Reply with quote

Well done, I'll give it a try and check with the results. Send an email to Fulvio to let him know of your patch so he can test it too.
Back to top
View user's profile Send private message Yahoo Messenger MSN Messenger
aviegas



Joined: 19 Jun 2010
Posts: 17

PostPosted: Wed Jun 30, 2010 2:25 pm    Post subject: Reply with quote

I'm send Fulvio an email.

Also, as I said, I been doing some testing and I've found 2 small problems.

1) The code I wrote to get the gw ip address was testing if the ethernet interface was DHCP based and if the interface was active. It turns out that the "if active" test causes a minor glitch in "routeupd" as it expects the old gateway IP to be able to properly remove the route. This is hard to notice because "failoverd" will eventually correct the problem.

The fixed version for my nb_getgwip is:
Code:
#!/bin/sh
. /etc/kerbynet.conf
GW="$1"
IP=`cat $GW/IP 2>/dev/null`
if [ -z "$IP" ] ; then
    INTERFACE=`cat $GW/Interface 2>/dev/null`
    if [ -n "$INTERFACE" ] ; then
        DHCP="$REGISTER/system/net/interfaces/$INTERFACE/dhclient"
        IP=`cat $DHCP/leases 2>/dev/null | grep routers |  awk  'END{sub(/\;/,"") ; print $3}'`
    fi
fi
echo $IP


2) nb_setnexthop has an odd behavior when deleting the existing default routes (just before adding the new ones). When a DHCP interface comes up, dhcpclient will add a standard default route for the newly aquired configuration. Like the previous state it needs to be purged to allow for the correct "nexthop" entry. It turns out that a single "ip ro del default" command only deletes the newly added DHCP route, leaving any other route there. This will cause the "ip ro add default $NEXTHOP" to fail and the routes to remain invalid. The solution here is simple: just add an extra "ip ro del defaul". Doing it twice ensure that the default route is not set, as required.

The code near the end of nb_setnexthop must read:
Code:
...
if [ "$CHANGE" = yes ] ; then
  ip ro del default 2>/dev/null
  ip ro del default 2>/dev/null  # Required to really delete in some cases, or add will not work correctly
  /usr/latest/ip ro add default $NEXTHOP
  echo $ACTIVEGW > /tmp/nb/ActiveGW
  logger -t NetBalancer "Default Route has been changed: $NEXTHOP"
else
....


I've tried several combinations of faults and it seems to be working fine.
Back to top
View user's profile Send private message
arfon



Joined: 20 Dec 2009
Posts: 29

PostPosted: Sun Jul 04, 2010 9:10 pm    Post subject: Reply with quote

Okay dumb question...


aviegas, if our zeroshell (beta 13) is running off of a USB flash drive, what is the correct way to add your modifications so they are there on reboots?
Back to top
View user's profile Send private message
ppalias



Joined: 17 Dec 2008
Posts: 1151
Location: Athens, Greece

PostPosted: Mon Jul 05, 2010 6:27 am    Post subject: Reply with quote

System -> Setup -> Startup/Cron
Add your modification here in a preboot or postboot script.
Back to top
View user's profile Send private message Yahoo Messenger MSN Messenger
arfon



Joined: 20 Dec 2009
Posts: 29

PostPosted: Wed Jul 14, 2010 11:28 pm    Post subject: Reply with quote

I'm sorry but I do not understand... How do you modify the kerby script using a pre-boot or a post-boot script?

And would the modification be pre or post boot?
Back to top
View user's profile Send private message
ppalias



Joined: 17 Dec 2008
Posts: 1151
Location: Athens, Greece

PostPosted: Fri Jul 16, 2010 1:30 pm    Post subject: Reply with quote

Make the modification you want and save it on a file, for example in
Code:
/Database/patch

Then add a preboot script to erase the old file
Code:
rm /root/kerbynet.cgi/......

and copy the modified file to its place
Code:
cp /Database/patch /root/kerbynet.cgi/fileneme

If you want to copy modied files use preboot. If you want to start services or run scripts use postboot.
Back to top
View user's profile Send private message Yahoo Messenger MSN Messenger
vladimird



Joined: 14 Oct 2015
Posts: 1

PostPosted: Fri Apr 08, 2016 10:07 am    Post subject: Reply with quote

Hi all,

I have a need also to update 2 DDNS host names over 2 wan connections. One is router and other is cable modem.
Was wondering if this was implemented in newer versions of zeroshell. I could not find this option but it would be nice to have it instead of trying to patch the actual one.
Back to top
View user's profile Send private message
iulyb



Joined: 02 Jun 2016
Posts: 88

PostPosted: Mon Jun 13, 2016 11:29 pm    Post subject: Reply with quote

Hi,
You can try to use a DDNS service that accept the IP as a variable and then use a script to extract the IP and post it to DDNS server.
I use Joker on my domain and has this options.

You will need about a 4 lines script that will go into cron section.

Code:

#/bin/bash

#get IPs
IP1=$(ifconfig ETH01 | awk '/inet addr/{print substr($2,6)}')
IP2=$(ifconfig ETH02 | awk '/inet addr/{print substr($2,6)}')

#post IPs
curl "http://svc.joker.com/nic/update?username=xxxxx&password=xxxx&hostname=bla.bla.com&ip=$IP1"
curl "http://svc.joker.com/nic/update?username=xxxxx&password=xxxx&hostname=bla.bla.com&ip=$IP2"
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    www.zeroshell.org Forum Index -> ZeroShell All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group