TCLUG Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
EQL & Masquerade...
Well, here's a challenge for the EQL savy out there (or rather
hopefully not a challenge for you, since I need your help).
Kernel: 2.2.5 - Compiled w/EQL & appropriate Firewall options
Hardware: 2 - USR 56K external modems (/dev/ttyS0, /dev/ttyS1)
Upstream Hdwr: Livingston Portmaster 3
Static IP Allocated: 209.18.238.8
Upstream IP: 209.18.238.3
Local Network: 192.168.2.0/24
NIC IP: 192.168.2.5
Objective: Use EQL to aggreate dialups into a shared bandwidth, then
masquerade local area network.
What works: PPP connections to internet work fine. Cron scheduling
works fine. EQL enslaving works fine.
Problem: Once the EQL device is configured and the pppX devices are
enslaved, no network communication to the internet is possible.
My Hunch: It looks like the EQL device works, as when I do a 'netstat
-i' I see counters for both TX-OK and TX-DRP. However, DNS does
not get resolved and connections cannot be established. This
leads me to believe that my ipchains are set up incorrectly...but
what do I know. I barely grasp IP Chains in the first place. :)
Why don't I show you what I've got, and you give me an analysis.
Here's what I've done...
1) Set up the EQL device in /etc/init.d/network
------------------------------------------------------------
# Set up EQL device
EQL_IP=209.18.239.8
EQL_NETMASK=255.255.255.255
EQL_MTU=1500
if [ "${EQL_IP}" ]; then
ifconfig eql ${EQL_IP} netmask ${EQL_NM} mtu ${EQL_MTU}
echo -n ", eql"
fi
------------------------------------------------------------
2) Set up my pppd options file...and symlinked it to
'/etc/ppp/peers/provider'
------------------------------------------------------------
asyncmap 0 # No hex chars
noauth # No authentication req'd
connect "/usr/sbin/chat -v -f /etc/chatscripts/WestCentral" # Connect
script
debug # Debug messages
user ltimold # User via PAP
idle 3600 # Disconnect after 1 hr inact..
holdoff 15 # 15 secs before redial
novj # Diasable Van-Jacobson
-vj
nodefaultroute # Don't set route tables
209.18.239.8:209.18.239.3
------------------------------------------------------------
3) Wrote ip-up.d/eql_enslave script for ppp connection...
------------------------------------------------------------
#!/bin/sh
# Enslave the new interface!
INTERFACE=$1
DEVICE=$2
SPEED=$3
LOCAL_IP=$4
REMOTE_IP=$5
# Load Balancing Configuration For Client Side
if [ -f /etc/ppp/eql_on_connect ]; then
# Enslave the device
echo "Enslaving interface $INTERFACE."
/usr/sbin/eql_enslave eql $INTERFACE $SPEED
# This re-adds the route in case its lost for one reason or
# another.
echo "Adding default route."
/sbin/route add default dev eql
fi
------------------------------------------------------------
4) Added the following lines to the /etc/crontab file to keep
the ppp connections up during the daytime hours (this is an office
I am setting this up for).
------------------------------------------------------------
# m h dom mon dow user command
*/1 8-18 * * 1-5 root /etc/cron.d/eql-up1 2>&1 dev/null
*/1 8-18 * * 1-5 root /etc/cron.d/eql-up2 2>&1 dev/null
------------------------------------------------------------
5) Added the scripts eql-up1 and eql-up2 to the cron.d directory for
step 4..
------------------------------------------------------------
#!/bin/sh
# /etc/cron.eql/eql-up1
# First cron script to maintain persistent connection to internet
PROVIDER=
LOCK=/var/run/ppp0.pid
if [ -f $LOCK ]; then
exit 0
else
to_kill=`cat $LOCK`
kill -9 ${to_kill}
start-stop-daemon --start --quiet \
--exec /usr/sbin/pppd -- /dev/ttyS0 call ${PROVIDER:-provider}
fi
# eql-up2 is identical except for using /dev/ttyS1
------------------------------------------------------------
6) Fired it all off...
NOTE: I've been using the Debian package for IPMASQ, which dynamically
sets up masquerading and the std firewall setup for the standard ppp
dialup (without eql). This works fine. However, in trying to figure
out what's wrong w/the eql communications, I disabled the package from
reapplying the firewall each dialup and ignored masquerading
altogether to try and get a successful standard connection to the
internet. No go. I may not understand the practical application of
IP Chains (although I've read the HOWTO a number of times), but
shouldn't a flushed chain stack w/a default policy of ACCEPT allow
everything through for standard connections?
HELP!
Chewie