Re: iptables and pptp - dialin
I have major problems setting up a ruleset of iptables rules for DSL
I'm using pptp to connect to my ISP. On the web, I have found a number
example configs... (of course I had a look at the docs :-)
Thats what I have got so far, but the connection is closed a few moments
applying the rules:
$IPTABLES -t filter -A INPUT -i $EXTIF -p tcp --dport 1723 -j ACCEPT
$IPTABLES -t filter -A INPUT -i $EXTIF -p gre -j ACCEPT
$IPTABLES -t filter -A FORWARD -i $EXTIF -o $INTIF -s $INTIP -d $INTIP
$IPTABLES -t filter -A FORWARD -o $EXTIF -i $INTIF -s $INTIP -d $INTIP
Try using a program(firehol) for setting up your firewall.
line 1+2 is more or less clear, but isn't there a OUTPUT necessary? And
are line 3+4 good vor? Do I have to set up a rule for the server IP
THX for any help
User against TCPA and public surveillance:
! This mail was sent using 100% recycled electrons.
I think you need to re read the way iptables works with the examples at the
bottom that I found very helpful trying to set up a firewall for the first
time, ( I couldnt get started with Firehol as I didnt have an already
working iptables config (I think thats what Firehol wanted anyway as it just
wouldnt run any configs I tried to input...? anyway I found that iptables
was actually ok itself once I found a basic "how to" written for a human
laymen not a robot!.. like a lot of Linux....ahem..)
I have 3 pdfs if you wish, at 600k each that explain the basics of iptables
very well - I can mail you if you like - let me know..
It seems that rules 3+4 below are a repeat and that you've made the source
the same as the destination, forwarding to itself??
Also gre relates to your ppp0 device when its offline doesnt it? It does
with my USB modem anyway... Therefore that line would be meaningless once
you tried to connect as there then is no device of that name...? Apart from
its named after the -p and "gre" isnt a protocol either is it - you need
icmp (ping), tcp or udp etc there.
OUTPUT chain is ONLY for any internally (host) generated comms to either the
input or the output interfaces ie both interfaces can be input or output
from the hosts viewpoint.
INPUT chain is for data entering the host from "outside" on either the input
(egLAN) or the output (egINTERNET) interface
FORWARD chain "crosses" inside the host to and from the input and output
interfaces ( I view it as effectively bypassing the host after being checked
at the borders)
Just start from scratch with
#iptables -F INPUT
to flush all rules from the INPUT chain, then build them up one at a time
after setting the default policy to ACCEPT from DENY for each chain if
neccessary for: INPUT, OUTPUT, and FORWARD chains.
You may find naming your devices less confusing by naming them eth0, eth1;
or eth0, ppp0; depending how your ADSL is setup. Use
rather than writing lines in a config file which I guess is what you have.
Admittedly I did everything on a testbox with Konqueror to check host tx/rx
whilst connected to the internet and could check each line worked or not as
I added it, so was a good way to learn what the hell was going on. I also
had a 2nd box connected as the "internal" lan so I could check that
forwarded to and from the internet was also working "across" the host. I ran
port scans to the host and the lan box from http://scan.sygate.com to check
the filtering/security as i added rules. Still havent locked it all down as
invisible but then...
hope this helps
Here is also a good mini how to I found with the basic examples you
need...writtten in (almost) English for once!
How to use IP Tables
I. Definitions and similarities to ipchains
II. Chain types and options
III. Command line examples
With the release of the 2.4 kernel, everyone who was used to using ipchains
to configure their firewall will now be looking at iptables. The native
packet filtering mechanism for the 2.4 kernel series is iptables, but you
can still compile in ipchains support at kernel configuration time.
I. What Are These "Chains"?
Just like its predecessor "ipchains", iptables uses a set of chain rules.
The three default chains are named INPUT, OUTPUT, and FORWARD. A chain is
just a simple checklist of rules and specifies what to do with each of the
packets. The chain rules will either ACCEPT a packet or DROP a packet (note
the "drop" syntax rather than "deny"). If the packet doesn't have anymore
rules left in the chain, the system will consult the chain policy to decide
what to do. Most systems are setup with a policy of deny. So if the packet
doesn't match any rules that "allow" it through, then it will "drop" it.
The first decision the kernel has to make upon receipt of a packet is "Where
is the destination?" If the destination is for the box itself it will
consult the rules for the INPUT chain. If the destination is for another
network interface (and you have IP Forwarding enabled), the packet is
compared against the FORWARD chain. As long as the packet gets an "ACCEPT"
by one of the chain rules the packet will be forwarded on. If the linux box
itself needs to send network packets, it will consult the OUTPUT chain and
if the packet is ACCEPT-ed by one of the rules it will be sent out to the
One of the key concepts for people transitioning from ipchains is to realize
that the INPUT and OUTPUT chains actually refer to the local machine rather
than to all incoming and outgoing packets. Another point to consider is the
use of "-o" to specify the interface. We used to use "-i" in ipchains to
refer to the interface. In iptables "-i" is only used when referring to the
incoming interface (so on the INPUT and FORWARD chains it is ok). So you are
pretty much going to want to use "-o" where you used to use the "-i". This
will refer to both the FORWARD and OUTPUT interface.
II. Chain types and options
As I mentioned, you have three basic chains:
However, you can create your own chains by using:
The above will create a new chain. Here are some more options to manipulate
-N Create a new chain
-X Delete an EMPTY chain
-P Change the Policy for a built-in chain
-L Lists the chain rules
-F Flushes the rules of a chain
-Z Sets the counters to zero on all the rules in a chain
III. Command line examples
Now for some options you can use to configure rules inside your chains:
-A Append a new rule
-I Insert a new rule
-R Replace a rule at a certain position
-D Delete a rule at a certain position
/sbin/iptables -A INPUT -p tcp -j ACCEPT
This rule would accept all tcp traffic. This is a little too broad isn't it?
Let's take a look at how we can specify some other options.
Taking it one step further:
-j Specify the target (--jump)
-i Specify the input interface (--in-interface)
-o Specify the output interface (--out-interface)
-p Specify the protocol (--proto)
-s Specify the source (--source)
-d Specify the destination (--destination)
! Specifies an inversion (match addresses NOT equal to)
Now we're talking! Let's try it...
/sbin/iptables -A FORWARD -s 192.168.1.0/24 -p tcp -j ACCEPT
This rule will allow traffic to be forwarded, as long as the protocol was
tcp, and the source was a machine on the 192.168.1.0 subnet
/sbin/iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
This rule, coupled with the one above will allow for MASQUERADE(ing) your
internal network traffic, via NAT (Network Address Translation), so that you
can share your internet connection with the rest of your network.
Some useful tcp options (these also work for udp):
--sport Filters on the source port
--dport Filters on the destination port
This is handy. Let's try it out!
This rule would allow traffic going to the www port (80) to be forwarded on.
/sbin/iptables -A FORWARD -p tcp --dport 80 -j ACCEPT
Change destination addresses of web traffic to 220.127.116.11, port 8080.
/sbin/iptables -t nat -A PREROUTING -p tcp --dport 80 -i eth0 -j DNAT --to
This allows you to filter on specific TCP flags. The first option after
"--tcp-flags" specifies which flags are to be examined, and the second
option specifies which flags are to be set.
Here is an example of the --tcp-flags in use:
/sbin/iptables -A INPUT -p tcp --tcp-flags ALL SYN -j DENY
Note: The list of possible flags is as follows
One of the other nice features is the ability to use the "! --syn" option.
This is equivalent to typing:
This would be useful in setting up your firewall to accept only connections
that were initiated internally.
I hope this helps!