Problems configuring iptables
Hi all,
I am new to iptables, so please bear with me here. I am configuring what I think is a fairy simple setup. I have a linux box which is acting as a network bridge that I want to install the firewall on. It has two ethernet cards: eth0 is attached to the internet, and eth1 is connected to the internal network. All machines inside the network use static public IP addresses, so there is no need to use NAT services or IP masquerading. I am setting it up to only accept SYN packets on certain TCP ports, then accept all packets on existing connections. The order would be:
ACCEPT SYN packets for certain TCP services.
DENY all other SYN packets on other TCP services.
ACCEPT all other TCP packets that are part of an existing connection. DENY all other TCP packets.
I started by changing the policies on INPUT AND FORWARD to drop all packets by default, and OUTPUT to accept.
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
Next, I added a rule to allow all traffic from the internal network to the outside world:
iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT
Next, a rule to forward packets that are part of an existing connection from eth0 to eth1.
iptables -A FORWARD -i eth0 -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT
Same thing, but on the firewall...
iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
And to allow all inputs from the internal network and local loopback to the firewall.
iptables -A INPUT -i eth1 -s 0/0 -d 0/0 -j ACCEPT
iptables -A INPUT -i lo -s 0/0 -d 0/0 -j ACCEPT
So after I set up these rules, if I understand iptables correctly, all traffic from inside the network should flow out smoothly over the bridge no matter what the internal IP address is nor what port the traffic is on. This, however, is not happening: no traffic can flow in or out of the network.
Also, if I try to add a rule to allow, say, SSH traffic to a specific machine behind the firewall, I run into other problems. If I type:
iptables -A FORWARD -s 0/0 -d w.x.y.z -p tcp --dport 22 --syn -j ACCEPT
This is, so far as I am aware, the format I would use. However, when I type iptables -L, the list just hangs just before listing that rule.
Can anyone offer any pointers as to what I may be doing wrong, and what I can do to get this working? Thanks!
Regards,
Matt
The 'hanging' is likely a result of a DNS lookup failing. If you add -n to your iptables command, it will not attempt to resolve DNS names, and may get you around at least that little part.
Ross A. Del Duca, GCIH
Quoted 23 lines
-----Original Message-----
From: [email protected] [mailto:netfilter- [email protected]] On Behalf Of Matt Singerman
Sent: Wednesday, August 23, 2006 8:49 AM
To: [email protected]
Subject: Problems configuring iptables< SNIP >
Also, if I try to add a rule to allow, say, SSH traffic to a specific machine behind the firewall, I run into other problems. If I type:
iptables -A FORWARD -s 0/0 -d w.x.y.z -p tcp --dport 22 --syn -j ACCEPT
This is, so far as I am aware, the format I would use. However, when I type iptables -L, the list just hangs just before listing that rule.
Can anyone offer any pointers as to what I may be doing wrong, and what I can do to get this working? Thanks!
Regards,
Matt
Hmmm... That is definitely part of it, yeah. But there is something else going on here.
So I tried changing the chain policy to ACCEPT and to just block all traffic using an iptables rule. When I implement the rules as follows, things work:
Chain FORWARD (policy ACCEPT)
target prot opt source destination ACCEPT tcp -- x.y.z.116 x.y.z.120 tcp dpt:ssh flags:FIN,SYN,RST,ACK/SYN DROP tcp -- anywhere anywhere tcp dpt:ssh flags:FIN,SYN,RST,ACK/SYN
As you can see, that is just blocking all traffic from anywhere to anywhere on port 22 after allowing traffic from x.y.z.116 to x.y.z.120 through. (x.y.z.116 and x.y.z.120 are both on the same subnet, but 120 is behind the firewall and 116 is not.) x.y.z.116 can SSH in to x.y.z.120, but nothing else can.
If I try to change it so that it isn't just blocking traffic on port 22, but rather all traffic:
Chain FORWARD (policy ACCEPT)
target prot opt source destination ACCEPT tcp -- x.y.z.116 x.y.z.120 tcp dpt:ssh flags:FIN,SYN,RST,ACK/SYN DROP tcp -- anywhere anywhere
No SSH connections can get through at all, even from host x.y.z.116.
Any ideas what could be causing this odd behavior?
Quoted 35 lines · Ross A. Del Duca
The 'hanging' is likely a result of a DNS lookup failing. If you add -n to your iptables command, it will not attempt to resolve DNS names, and may get you around at least that little part.
Ross A. Del Duca, GCIH
Quoted 26 lines
-----Original Message-----
From: [email protected] [mailto:netfilter- [email protected]] On Behalf Of Matt Singerman
Sent: Wednesday, August 23, 2006 8:49 AM
To: [email protected]
Subject: Problems configuring iptables< SNIP >
Also, if I try to add a rule to allow, say, SSH traffic to a specific machine behind the firewall, I run into other problems. If I type:
iptables -A FORWARD -s 0/0 -d w.x.y.z -p tcp --dport 22 --syn -j ACCEPT
This is, so far as I am aware, the format I would use. However, when I type iptables -L, the list just hangs just before listing that rule.
Can anyone offer any pointers as to what I may be doing wrong, and what I can do to get this working? Thanks!
Regards,
Matt
Wow, that came out looking all messed up, let me try sending that again:
Hmmm... That is definitely part of it, yeah. But there is something else going on here.
So I tried changing the chain policy to ACCEPT and to just block all traffic using an iptables rule. When I implement the rules as follows, things work:
Chain FORWARD (policy ACCEPT)
target prot opt source destination ACCEPT tcp -- x.y.z.116 x.y.z.120 tcp dpt:ssh flags:FIN,SYN,RST,ACK/SYN DROP tcp -- anywhere anywhere tcp dpt:ssh flags:FIN,SYN,RST,ACK/SYN
As you can see, that is just blocking all traffic from anywhere to anywhere on port 22 after allowing traffic from x.y.z.116 to x.y.z.120 through. (x.y.z.116 and x.y.z.120 are both on the same subnet, but 120 is behind the firewall and 116 is not.) x.y.z.116 can SSH in to x.y.z.120, but nothing else can.
If I try to change it so that it isn't just blocking traffic on port 22, but rather all traffic:
Chain FORWARD (policy ACCEPT)
target prot opt source destination ACCEPT tcp -- x.y.z.116 x.y.z.120 tcp dpt:ssh flags:FIN,SYN,RST,ACK/SYN DROP tcp -- anywhere anywhere
No SSH connections can get through at all, even from host x.y.z.116.
Any ideas what could be causing this odd behavior?
Quoted 58 lines · Matt Singerman
Hmmm... That is definitely part of it, yeah. But there is something else going on here.
So I tried changing the chain policy to ACCEPT and to just block all traffic using an iptables rule. When I implement the rules as follows, things work:
Chain FORWARD (policy ACCEPT)
target prot opt source destination ACCEPT tcp -- x.y.z.116 x.y.z.120 tcp dpt:ssh flags:FIN,SYN,RST,ACK/SYN DROP tcp -- anywhere anywhere tcp dpt:ssh flags:FIN,SYN,RST,ACK/SYNAs you can see, that is just blocking all traffic from anywhere to anywhere on port 22 after allowing traffic from x.y.z.116 to x.y.z.120 through. (x.y.z.116 and x.y.z.120 are both on the same subnet, but 120 is behind the firewall and 116 is not.) x.y.z.116 can SSH in to x.y.z.120, but nothing else can.
If I try to change it so that it isn't just blocking traffic on port 22, but rather all traffic:
Chain FORWARD (policy ACCEPT)
target prot opt source destination ACCEPT tcp -- x.y.z.116 x.y.z.120 tcp dpt:ssh flags:FIN,SYN,RST,ACK/SYN DROP tcp -- anywhere anywhereNo SSH connections can get through at all, even from host x.y.z.116.
Any ideas what could be causing this odd behavior?
Quoted 36 lines · Ross A. Del Duca
The 'hanging' is likely a result of a DNS lookup failing. If you add -n to
your iptables command, it will not attempt to resolve DNS names, and may get you around at least that little part.Ross A. Del Duca, GCIH
Quoted 26 lines
-----Original Message-----
From: [email protected] [mailto:netfilter- [email protected]] On Behalf Of Matt Singerman
Sent: Wednesday, August 23, 2006 8:49 AM
To: [email protected]
Subject: Problems configuring iptables< SNIP >
Also, if I try to add a rule to allow, say, SSH traffic to a specific machine behind the firewall, I run into other problems. If I type:
iptables -A FORWARD -s 0/0 -d w.x.y.z -p tcp --dport 22 --syn -j ACCEPT
This is, so far as I am aware, the format I would use. However, when I type iptables -L, the list just hangs just before listing that rule.
Can anyone offer any pointers as to what I may be doing wrong, and what I can do to get this working? Thanks!
Regards,
Matt
Quoted 14 lines · Matt Singerman
Wow, that came out looking all messed up, let me try sending that again:
Hmmm... That is definitely part of it, yeah. But there is something else going on here.
So I tried changing the chain policy to ACCEPT and to just block all traffic using an iptables rule. When I implement the rules as follows, things work:
Chain FORWARD (policy ACCEPT)
target prot opt source destination ACCEPT tcp -- x.y.z.116 x.y.z.120 tcp dpt:ssh flags:FIN,SYN,RST,ACK/SYN DROP tcp -- anywhere anywhere tcp dpt:ssh flags:FIN,SYN,RST,ACK/SYNAs you can see, that is just blocking all traffic from anywhere to anywhere on port 22 after allowing traffic from x.y.z.116 to x.y.z.120 through. (x.y.z.116 and x.y.z.120 are both on the same subnet, but 120 is behind the firewall and 116 is not.) x.y.z.116 can SSH in to x.y.z.120, but nothing else can.
If I try to change it so that it isn't just blocking traffic on port 22, but rather all traffic:
Quoted 8 lines
Chain FORWARD (policy ACCEPT)
target prot opt source destination ACCEPT tcp -- x.y.z.116 x.y.z.120 tcp dpt:ssh flags:FIN,SYN,RST,ACK/SYN DROP tcp -- anywhere anywhereNo SSH connections can get through at all, even from host x.y.z.116.
Any ideas what could be causing this odd behavior?
Nothing odd here. First you allow all all syns from .116 to .120. You dorp all other syns. You allow all other traffic, which includes all non-syn traffic. In the second scenario you aloow the syns, but frop all non syn traffic. So the syn gets through, but the syn-ack from the ssh server gets dropped.
What you should be doing is this:
# let through all traffic from established connections -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT # let through the connection request -A FORWARD -p tcp --dport 22 -s x.y.z.116 -d x.y.z.130 -j ACCEPT # log and drop all other traffic -A FORWARD -j LOG -A FORWARD -j DROP
For further information, read the howtos at the www.netfilter.org site.
HTH,
M4
Quoted 37 lines · Martijn Lievaart
Quoted 14 lines · Matt Singerman
Wow, that came out looking all messed up, let me try sending that again:
Hmmm... That is definitely part of it, yeah. But there is something else going on here.
So I tried changing the chain policy to ACCEPT and to just block all traffic using an iptables rule. When I implement the rules as follows, things work:
Chain FORWARD (policy ACCEPT)
target prot opt source destination ACCEPT tcp -- x.y.z.116 x.y.z.120 tcp dpt:ssh flags:FIN,SYN,RST,ACK/SYN DROP tcp -- anywhere anywhere tcp dpt:ssh flags:FIN,SYN,RST,ACK/SYNAs you can see, that is just blocking all traffic from anywhere to anywhere on port 22 after allowing traffic from x.y.z.116 to x.y.z.120 through. (x.y.z.116 and x.y.z.120 are both on the same subnet, but 120 is behind the firewall and 116 is not.) x.y.z.116 can SSH in to x.y.z.120, but nothing else can.
If I try to change it so that it isn't just blocking traffic on port 22, but rather all traffic:
Quoted 8 lines
Chain FORWARD (policy ACCEPT)
target prot opt source destination ACCEPT tcp -- x.y.z.116 x.y.z.120 tcp dpt:ssh flags:FIN,SYN,RST,ACK/SYN DROP tcp -- anywhere anywhereNo SSH connections can get through at all, even from host x.y.z.116.
Any ideas what could be causing this odd behavior?
Nothing odd here. First you allow all all syns from .116 to .120. You dorp all other syns. You allow all other traffic, which includes all non-syn traffic. In the second scenario you aloow the syns, but frop all non syn traffic. So the syn gets through, but the syn-ack from the ssh server gets dropped.
What you should be doing is this:
# let through all traffic from established connections -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT # let through the connection request -A FORWARD -p tcp --dport 22 -s x.y.z.116 -d x.y.z.130 -j ACCEPT # log and drop all other traffic(quoted diff) +0
-2-A FORWARD -j LOG -A FORWARD -j DROP
Quoted 5 lines
For further information, read the howtos at the www.netfilter.org site.
HTH,
M4
Hi Martijn,
This did work, yes! Thanks! I am experiencing a new problem, though: it took an extremely long time for the connection to go through. Once it connected, it runs at normal speed, but it took a good 30 or 40 seconds for ssh to prompt me for my password. What could be causing this? I am guessing it is some sort of routing issue?
Quoted 11 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Matt Singerman
Sent: Wednesday, August 23, 2006 2:58 PM
To: Martijn Lievaart
Cc: [email protected]
Subject: Re: Problems configuring iptables
Quoted 5 lines
it took an extremely long time for the connection to go through. Once it connected, it runs at normal speed, but it took a good 30 or 40 seconds for ssh to prompt me for my password. What could be causing this? I am guessing it is some sort of routing issue?
Usually this means ssh isn't resolving properly. I'd guess your /etc/resolv.conf file isn't setup properly. Ensure the nameserver values point to your ISP.
Cheers,
---
Pablo Sanchez - Blueoak Database Engineering, Inc
Ph: 819.459.1926 Toll free: 888.459.1926 Cell: 819.918.9731 Pgr: [email protected] Fax: 603.720.7723 (US)
Quoted 17 lines · Pablo Sanchez
Quoted 12 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Matt Singerman
Sent: Wednesday, August 23, 2006 2:58 PM
To: Martijn Lievaart
Cc: [email protected]
Subject: Re: Problems configuring iptablesit took an extremely long time for the connection to go through. Once it connected, it runs at normal speed, but it took a good 30 or 40 seconds for ssh to prompt me for my password. What could be causing this? I am guessing it is some sort of routing issue?
Usually this means ssh isn't resolving properly. I'd guess your
/etc/resolv.conffile isn't setup properly. Ensure the nameserver values point to your ISP.
Quoted 9 lines
Cheers,
---
Pablo Sanchez - Blueoak Database Engineering, IncPh: 819.459.1926 Toll free: 888.459.1926 Cell: 819.918.9731 Pgr: [email protected] Fax: 603.720.7723 (US)
Hi Pablo,
resolv.conf appears to be set up correctly. Also, if I turn off the firewall and just let traffic flow through the bridge unfettered, connections are much snappier. Actually, if I flush the rules, it is just as fast with the firewall off. Any ideas what else it could be?
Quoted 2 lines · Matt Singerman
This did work, yes! Thanks! I am experiencing a new problem, though: it took an extremely long time for the connection to go through. Once it connected, it runs at normal speed, but it took a good 30 or 40 seconds for ssh to prompt me for my password. What could be causing this? I am guessing it is some sort of routing issue?
Ah no. It's either reverse DNS or ident that trips you up. Ethereal is your friend, look what goes on "at the wire".
M4
Martijn Lievaart írta:
Quoted 10 lines
Quoted 2 lines · Matt Singerman
This did work, yes! Thanks! I am experiencing a new problem, though: it took an extremely long time for the connection to go through. Once it connected, it runs at normal speed, but it took a good 30 or 40 seconds for ssh to prompt me for my password. What could be causing this? I am guessing it is some sort of routing issue?
Ah no. It's either reverse DNS or ident that trips you up. Ethereal is your friend, look what goes on "at the wire".
M4
I am not sure... but maybe your script blocks the DNS service... Try it on your firewalled server and on a client behind the firewall...
(host www.netfilter.org AND nslookup www.netfilter.org)
Quoted 7 lines · Gáspár Lajos
Martijn Lievaart írta:
Quoted 6 lines
Quoted 2 lines · Matt Singerman
This did work, yes! Thanks! I am experiencing a new problem, though: it took an extremely long time for the connection to go through. Once it connected, it runs at normal speed, but it took a good 30 or 40 seconds for ssh to prompt me for my password. What could be causing this? I am guessing it is some sort of routing issue?
Ah no. It's either reverse DNS or ident that trips you up. Ethereal is your friend, look what goes on "at the wire".
Quoted 7 lines
Quoted 4 lines
M4
I am not sure... but maybe your script blocks the DNS service... Try it on your firewalled server and on a client behind the firewall...
(host www.netfilter.org AND nslookup www.netfilter.org)
So I think the problem was that traffic was not able to flow back out over the connection from within the firewall. I set up a ne rule allowing all packets from the internal NIC to head out over the external NIC, regardless of type or state, and that cleared up the problem instantly. Thanks again for all the help, everyone!