Dammit... I REALLY need to remember to send to the list from the right
address. I originally sent this last night:
---------
Man, I wish I had paid more attention to you guys at the meeting. I came
over almost at the end and didn't get a chance to really look at it. The
answer (I hope!) is adding this line:
$IPT -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables was doing exactly what it was told to do. A ping got received from
the internal net, hit the FORWARD chain and got accepted by the second rule.
It went on to the POSTROUTING chain and was correctly masqueraded, and left
on it's journey across the net. The response, unfortunately, didn't fare so
well. It was automatically demasqed (unmasqed? :) when it arrived in the IP
stack, but when it hit the FORWARD chain it died since there was no rule
that it matched. The only automatic part about masquerading is the
corresponding demasquerading when a related packet comes in. For every
single packet, somewhere in the series of chains there has to be a rule that
matches and accepts it. In fact, if you want to be able to connect to
anything on the internet, you need to add a rule like this also:
$IPT -A INPUT -i ppp0 -m state --state ESTABLISHED,RELATED -j ACCEPT
The OUTPUT chain's default policy is ACCEPT, so anything coming straight
from the firewall box will go out just fine, but any response will be
dropped without the state match.
There's a pretty good HOWTO by Rusty Russell, one of the core netfilter
devel guys.
http://netfilter.filewatcher.org/unreliable-guides/index.html
There's also some good stuff at http://www.e-infomax.com/ipmasq/
Also, on a minor note, you don't need to specify those final -j DROP rules
if you change the policy to DROP on the INPUT, OUTPUT, and FORWARD chains.
If you are planning to use active ftp or IRC, you might want to modprobe the
relevant modules at the beginning of the script. Those are the only 2
protocol helper modules in the stock kernel. I'm not sure it's 100%
necessary to manually modprobe these, but I know it works. :) Without these
irc breaks in wierd ways, and active mode ftp is flat impossible.
/sbin/modprobe ip_conntrack_ftp
/sbin/modprobe ip_conntrack_irc
/sbin/modprobe ip_nat_ftp
/sbin/modprobe ip_nat_irc
As usual, my answer is surely a lot longer than you needed, but I hope it
helped you. :)
-Ken
-----Original Message-----
From: slug@lists.nks.net [mailto:slug@lists.nks.net]On Behalf Of Larry
Sanders
Sent: Wednesday, December 12, 2001 11:19 PM
To: slug@nks.net
Subject: [SLUG] IPtables drops all
At the meeting tonight, thanks to Mat and Greg, we proved that
iptables is working so well that nothing was getting in from ppp0.
In a P75 w/24mb ram and two ne2000 nics, we could login to an
ISP with the modem, and traffic was sent and received then dropped.
Here is the shell used to setup the rules, the listing, and the log.
<</etc/rc.d/init.d/rc.firewall>> (this is Derek's rules with two nics)
# rc.firewall iptables to protect internal network
# by Derek Glidden at www.nks.net - July 2001
# add eth1 by Larry Sanders, Dec 2001
#
# turn forwarding off while vulnerable
echo "0" > /proc/sys/net/ipv4/ip_forward
#
/sbin/iptables -F # flush all rules
# rule to nat if from inside going out
/sbin/iptables -t nat -A POSTROUTING -o ppp0 \
-s 192.168.27.0/24 -j MASQUERADE
/sbin/iptables -t nat -A POSTROUTING -o ppp0 \
-s 192.168.127.0/24 -j MASQUERADE
# rule to accept if from inside with good ip
/sbin/iptables -A FORWARD -i eth0 -s 192.168.27.0/24 -o ppp0 -j ACCEPT
/sbin/iptables -A FORWARD -i eth1 -s 192.168.127.0/24 -o ppp0 -j ACCEPT
# rule to log any not accepted
/sbin/iptables -A FORWARD -j LOG --log-prefix="FORWARD DROP:"
# rule to drop any not accepted
/sbin/iptables -A FORWARD -j DROP
#
# rule to accept input from internal lan
# /sbin/iptables -A INPUT -i eth0 -s 192.168.27.0/24 -j ACCEPT
/sbin/iptables -A INPUT -i eth1 -s 192.168.127.0/24 -j ACCEPT
# rule to explicitly log and drop all others
# /sbin/iptables -A INPUT -j LOG --log-prefix="INPUT DROP:"
/sbin/iptables -A INPUT -j DROP
#
# turn on forwarding with wall constucted
echo "1" > /proc/sys/net/ipv4/ip_forward
echo iptables set for firewall in file rc.firewall
# end of firewall
======================================================
Then here is the listing from: iptables -L -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination
0 0 ACCEPT all -- eth1 any 192.168.127.0/24 anywhere
0 0 DROP all -- any any anywhere anywhere
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination
0 0 ACCEPT all -- eth0 ppp0 192.168.27.0/24 anywhere
0 0 ACCEPT all -- eth1 ppp0 192.168.127.0/24 anywhere
0 0 LOG all -- any any anywhere anywhere
LOG level warning prefix `FORWARD DROP:'
0 0 DROP all -- any any anywhere anywhere
Chain OUTPUT (policy ACCEPT 24 packets, 2016 bytes)
pkts bytes target prot opt in out source
destination
======================================================
And here is the entry in the /var/log/messages from when a user on the
trusted
network (192.168.127.2) pinged the name server for the ISP.
Dec 12 20:37:57 gate kernel: FORWARD DROP:IN=ppp0 OUT=eth1
SRC=207.115.59.241 DST=192.168.127.2 LEN=140 TOS=0x00 PREC=0x00
TTL=11 ID=34185 PROTO=UDP SPT=53 DPT=1521 LEN=120
Why is this packet, comming in on ppp0, dropped?? Why is this anser to a
ping not
being recognized as an answer to this ping?
Derek, Thanks in advance.
Larry S.
:-)
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 20:12:13 EDT