> Kevin Buettner <kev@primenet.com> writes:
> >I have been unable to get either diald-0.11 or diald-0.12 to work with
> >linux kernel 1.3.72 (built with IP forwarding, firewalling, and
> >masquerading). OTOH, diald-0.11 is working well with 1.3.70 and several
> >earlier versions in the 1.3.X series (configured the same).
>
> Are you making active use of all these features?
Yes. One thing that I forgot to mention is that I also have the following
lines in my /etc/rc.d/rc.local...
## Masquerading/Firewalling for 1.3.66 and later (?)
if [ -x /sbin/ipfwadm ]; then
/sbin/ipfwadm -I -f # flush "Input" rules
/sbin/ipfwadm -O -f # flush "Output" rules
/sbin/ipfwadm -F -f # flush "Forwarding" rules
# Enable masquerading as the default forwarding policy
#/sbin/ipfwadm -F -p masquerade
# Set default forwarding policy to deny and masquerade the private
# network
/sbin/ipfwadm -F -p deny
/sbin/ipfwadm -F -a masquerade -S 192.168.2.0/24 -D 0.0.0.0/0
# Don't let any packets from the internal network "leak" out
/sbin/ipfwadm -O -a deny -W ppp0 -S 192.168.2.0/24 \
-D 0.0.0.0/0
# Disable access to certain tcp ports that we don't want to give
# any access to.
/sbin/ipfwadm -I -a deny -W ppp0 -P tcp -S 0.0.0.0/0 \
-D 0.0.0.0/0 23 513 514
# Enable access from the outside for the reserved tcp ports only when the
# ACK bit is set. We also give total access to identd (port 113). The
# reason for giving total access to identd is so that hosts which we
# rlogin to can verify who we are.
/sbin/ipfwadm -I -a accept -W ppp0 -P tcp -k -S 0.0.0.0/0 \
-D 0.0.0.0/0 1:1023
/sbin/ipfwadm -I -a accept -W ppp0 -P tcp -S 0.0.0.0/0 \
-D 0.0.0.0/0 113
/sbin/ipfwadm -I -a deny -W ppp0 -P tcp -S 0.0.0.0/0 \
-D 0.0.0.0/0 1:1023
# Enable (udp) dns
/sbin/ipfwadm -I -a accept -W ppp0 -P udp -S 0.0.0.0/0 \
-D 0.0.0.0/0 53
# Disable the low numbered udp ports
/sbin/ipfwadm -I -a deny -W ppp0 -P udp -S 0.0.0.0/0 \
-D 0.0.0.0/0 1:1023
fi
The line in all the above which looked worrisome was the line where I set
the forwarding policy to deny. So I made the default forwarding policy
"accept". No change. After trying a bunch of other stuff, I nuked all the
above rules entirely and made the default policy accept for the input,
output, and forwarding rules. (This is basically turning off masquerading
and firewalling all together.) Still didn't work. So I re-enabled all
of the above rules and manually changed the default route to go to ppp0
directly and things worked again.
> I've got diald
> running with 1.3.72, but I don't have IP forwarding turned on,
> and although I have firewalling and masquerading compiled, I'm
> not actually using them. If you can isolate which feature
> is causing the problem it would probably help me track this down.
Um, ok. I gather you want me to change my kernel configuration, recompile,
and try again?
May take a while, but I'll give it a go. BTW, it was my impression that
IP masquerading and firewalling required that IP forwarding be enabled.
Am I mistaken?
> >FYI, "netstat -rn" yields the following:
> >
> >Kernel routing table
> >Destination Gateway Genmask Flags Metric Ref Use Iface
> >127.0.0.2 0.0.0.0 255.255.255.255 UH 0 0 0 sl0
> >204.245.20.28 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
> >192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 9 eth0
> >127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 67 lo
> >0.0.0.0 127.0.0.2 0.0.0.0 UG 0 0 496 sl0
>
> Was this the routing table built by diald on its own, or is this what
> you got after you added a new default route by hand?
With the exception of the eth0 and lo lines, the above is what diald builds
on its own. Here is what it looks like if I delete and then add the
default route myself:
redrock:kev# /sbin/route del default
redrock:kev# /sbin/route add default ppp0
redrock:kev# /sbin/route -n
Kernel routing table
Destination Gateway Genmask Flags MSS Window Use Iface
127.0.0.2 * 255.255.255.255 UH 1500 0 0 sl0
204.245.18.16 * 255.255.255.255 UH 1500 0 1 ppp0
192.168.2.0 * 255.255.255.0 U 1500 0 0 eth0
127.0.0.0 * 255.0.0.0 U 3584 0 7 lo
default * * U 1500 0 6 ppp0
>
> >I am using the following command to start diald up in /etc/rc.d/rc.local:
> >
> > /usr/sbin/diald /dev/cua1 -m ppp local 204.245.17.205 remote 127.0.0.2 \
> > defaultroute modem crtscts redial-timeout 7 \
> > connect /usr/sbin/chatter fifo /etc/diald/fifo \
> > -- asyncmap 0
>
> Hmm. Looking at this it is possible that diald is mucking up because the
> remote address does not reflect the real remote address (perhaps
> a new layer of filtering was added to the kernel IP code).
> Try adding the "dynamic" option to the list of diald options and
> see if this helps.
I tried adding "dynamic". It made no appreciable difference.
Just to be clear on this, the above now looks like this:
/usr/sbin/diald /dev/cua1 -m ppp local 204.245.17.205 remote 127.0.0.2 \
defaultroute modem crtscts redial-timeout 7 \
connect /usr/sbin/chatter fifo /etc/diald/fifo \
dynamic -- asyncmap 0