Re: Debian Sarge masq problem
Hello,
Anthony Lupidi a écrit :
I have just installed Debian 3.1 stable on a machine I
have used previously as a route/firewall soho server
under an ancient version of redhat.
This machine has two nics, one connected to the adsl
using pppoe and one connected to the internal lan.
After installing and setting up NAT/PAT firewall only
one machine on the internal lan can reliably access
the internet through the debian machine, (there are 4
machines on the local lan).
Can you elaborate "cannot reliably access the internet" please ?
Which types of communication work, which ones do not ?
What are your iptables and kernel versions ?
When running tracert from the problem windows machines
on the internal net there are timeouts tracing routes
to different internet servers after 6 or 7 jumps,
sometimes on the first jump. Strangely I can reliably
ping these same hosts no problem.
What about the traceroute from the other machine, the one that works
fine ? What about connections between the machines and the
router/firewall (to make sure the problem is not local) ?
Whenever I read PPPoE, a little bell rings saying "beware the MTU
limit". What is the MTU of your PPP interface ? You can try to lower the
MTU on the machines to 1492 or less, or if TCP connections are most
affected you can try to clamp the MSS of TCP connections with the TCPMSS
target on the router/firewall.
------ below is the firewall.sh script ------
This ruleset contains some mistakes, which are not related to your
problem. I commented it.
[...]
# Enter the designation for the Internal Interface's
INTIF="eth1"
# Enter the NETWORK address the Internal Interface is on
INTNET="192.168.0.0/24"
# Enter the IP address of the Internal Interface
INTIP="192.168.0.50/24"
I think you should not specify a prefix length here. It is a single
address, not a block. Anyway I guess it won't harm, it is juste more
permissive.
# SET YOUR EXTERNAL INTERFACE FOR DYNAMIC IP ADDRESSING
# If you get your IP address dynamically from SLIP, PPP,
# BOOTP, or DHCP, UNCOMMENT the command below.
# (No values have to be entered.)
# Note that if you are uncommenting these lines then
# the EXTIP line in Section B must be commented out.
EXTIP="`/sbin/ifconfig ppp0 | grep 'inet addr' | awk
'{print $2}' | sed -e 's/.*://'`"
By the way, a much more elegant and convenient way to retrieve a dynamic
PPP interface name and address is to use the environment variable
$PPP_IFACE and $PPP_LOCAL in a custom script you put in
/etc/ppp/ip-up.d/ which is run by pppd each time the connection is
established or re-established.
[...]
# Clear any existing rules and setting default policy to DROP
iptables -P INPUT DROP
iptables -F INPUT
iptables -P OUTPUT DROP
iptables -F OUTPUT
iptables -P FORWARD DROP
iptables -F FORWARD
iptables -F -t nat
# Flush the user chain.. if it exists
if [ "`iptables -L | grep drop-and-log-it`" ]; then
iptables -F drop-and-log-it
fi
All the 'filter' table chains could be flushed with a single command,
just like the 'nat' table chains :
iptables -F
[...]
# Creating a DROP chain
iptables -N drop-and-log-it
iptables -A drop-and-log-it -j LOG --log-level info
iptables -A drop-and-log-it -j REJECT
REJECT is a good idea, more compliant to the standard than DROP in most
cases, but not always. Only valid packets should be REJECTed so the
sender is notified. But, for instance, packets in the INVALID state and
spoofed packets should be DROPped. Also, the name of the user chain is
quite misleading.
# remote interface, claiming to be local machines, IP spoofing, get lost
iptables -A INPUT -i $EXTIF -s $INTNET -d $UNIVERSE -j drop-and-log-it
As I wrote above, spoofed packets should be DROPped instead of REJECTed.
Also, you could save that rule by enabling the reverse path filtering
(source address spoof protection) on the external interface in the
kernel routing parameters :
echo "1" > /proc/sys/net/ipv4/conf/all/rp_filter
echo "1" > /proc/sys/net/ipv4/conf/$EXTIF/rp_filter
# remote interface, any source, going to permanent PPP address is valid
iptables -A INPUT -i $EXTIF -s $UNIVERSE -d $EXTIP -j ACCEPT
Gasp ! That rule just accepts *anything* on the external interface. Is
that really what you want ? If so, the next INPUT rules on that
interface are useless since this one is more permissive.
# OPTIONAL: Uncomment the following two commands if plan on running
# an Apache Web site on the firewall server itself
#
#echo -e " - Allowing EXTERNAL access to the WWW server"
#iptables -A INPUT -i $EXTIF -m state --state
NEW,ESTABLISHED,RELATED -p tcp -s $UNIVERSE -d $EXTIP --dport 80 -j ACCEPT
Ok, that rule is disabled. But if you want to enable it, you don't need
the ESTABLISHED state here since it is already managed by a previous
rule, neither the RELATED state since an HTTP connection is not supposed
to be related to any other connection. Anyway it won't harm.
# Catch all rule, all other incoming is denied and logged.
iptables -A INPUT -s $UNIVERSE -d $UNIVERSE -j drop-and-log-it
Packets with the INVALID state should be DROPped instead of REJECTED.
You may also want to accept incoming ICMP echo-reply (ping), it is safe
and can be useful for troubleshooting purpose. I do and do not worry
about it at all.
[...]
# outgoing to local net on remote interface, stuffed routing, deny
iptables -A OUTPUT -o $EXTIF -s $UNIVERSE -d $INTNET
-j drop-and-log-it
I don't see the point of that rule, unless the routing table of your
router/firewall is broken.
[...]
# FORWARD: Enable Forwarding and thus IPMASQ
# Allow all connections OUT and only existing/related IN
iptables -A FORWARD -i $EXTIF -o $INTIF -m state
--state ESTABLISHED,RELATED -j ACCEPT
I would restrict this rule with '-d $INTNET'.
Also, I do not see any spoof protection as in the INPUT chain.
iptables -A FORWARD -i $INTIF -o $EXTIF -j ACCEPT
I would restrict this rule with '-s $INTNET'.
# Enable SNAT (MASQUERADE) functionality on $EXTIF
iptables -t nat -A POSTROUTING -o $EXTIF -j SNAT --to $EXTIP
I would restrict this rule with '-s $INTNET'.
Reply to: