[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian Sarge masq problem


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

# Enter the NETWORK address the Internal Interface is on

# Enter the IP address of the Internal Interface

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.

#   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

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

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

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: