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

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

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.

hi Manfred
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 appropriate interface.

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:
/sbin/iptables -N

The above will create a new chain. Here are some more options to manipulate your chains:

-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

For example:

/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 -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 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, 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:
--tcp-flags ACK,FIN,RST,URG,PSH

This would be useful in setting up your firewall to accept only connections that were initiated internally.

I hope this helps!


Reply to: