iptables help anyone?

Scarpozzi

Lifer
Jun 13, 2000
26,391
1,780
126
I've got a server with 2 interfaces eth0 and eth1. I'm trying to maintain security on eth0 so it's not open to anyone outside of some particular vlans. It's configured and has worked great. I recently wanted to open web traffic up to the system, but need to do this over a new interface to protect the server and http content on eth0.

I setup eth1 to do this.

I've got a lot of rules specific to eth0, but never referenced eth0 in the rule. For example, this rule is in place to allow traffic to port 80 from 2.231:
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 80 -s 192.168.2.231 -j ACCEPT

When I added eth1, my eth1 entries look like this:

-A RH-Firewall-1-INPUT -i eth1 -p tcp --dport 8443 -d 192.168.1.106 -j ACCEPT
-A RH-Firewall-1-INPUT -o eth1 -p tcp --sport 8443 -d 192.168.1.106 -j ACCEPT

-A RH-Firewall-1-INPUT -i eth1 -p tcp --dport 9443 -d 192.168.1.106 -j ACCEPT
-A RH-Firewall-1-INPUT -o eth1 -p tcp --sport 9443 -d 192.168.1.106 -j ACCEPT

What's confusing me is that 9443 stopped talking about 30 minutes ago and I can't get it to work. Port 8443 continues to work. I can turn iptables off and everything works. I made no changes to iptables and it started acting up...any ideas why it worked before and it's not now? Is there a better way to do it? Most of the documentation I find for iptables when searching for 2 nics results in all the gateway configurations. I'm just trying to configure a 2 interface box to split security.
 

KillerBee

Golden Member
Jul 2, 2010
1,750
82
91
I would start with a -j LOG (everything from a specific machine that you are using to test from) type rule

which may help you see where or if it is getting dropped.
 

Scarpozzi

Lifer
Jun 13, 2000
26,391
1,780
126
I would start with a -j LOG (everything from a specific machine that you are using to test from) type rule

which may help you see where or if it is getting dropped.

I'm currently using one. I think I'm already seeing what's happening, but it's not making much sense. For some reason it logged an error on eth0 with the DST being eth1's ip address.

I know it *was* working earlier today.
 

mv2devnull

Golden Member
Apr 13, 2010
1,519
154
106
Good god, iptables. *cringes*
The positive thing about that comment is the reference to good god rather than evil something.

It is hard to say what is wrong with the ruleset without seeing all of it. Chains are evaluated in order, and first match usually takes the packet out of the ride.

Additional tip is to use multiple chains when hand-crafting rules. We have seen so far the chain "RH-Firewall-1-INPUT" which I bet to be entered from both INPUT and FORWARD chains.

In RHEL-6 RedHat has dropped that common chain and puts default rules directly to default chains. While there is some duplication, it is also obvious that incoming and routed traffic should be handled differently. OP clearly has no traffic in FORWARD, so trivial REJECT there would be nice for completeness.

Back to the custom chains.

INPUT:
ESTABLISHED,RELATED -j ACCEPT
-i lo -j ACCEPT
some icmp -j ACCEPT
-i eth0 -j Limited
-i eth1 -j Web
-j REJECT

Limited:
Whatever you want to accept via eth0. No need to test for "-i eth0" again.
Ends with REJECT.

Web:
Rules for eth1.


Note on the eth1 rules:
"-o eth1" would only match on FORWARD/OUTPUT outgoing packets. There is no routing, yes?
 

Scarpozzi

Lifer
Jun 13, 2000
26,391
1,780
126
I might give up on this and just move the less secure web traffic to another server. I was just trying to centralize certs and connect to the local mySQL server....

That just seems easier than rewriting all my other iptables entries to try to fix the 6 entries I need for these web servers. :p
 

Scarpozzi

Lifer
Jun 13, 2000
26,391
1,780
126
Note on the eth1 rules:
"-o eth1" would only match on FORWARD/OUTPUT outgoing packets. There is no routing, yes?

Correct...no routing. Both eth0 and eth1 are actually on the same subnet. I changed ips to protect the innocent. Basically I just want traffic to stick to the interface that the client starts talking to via DNS.
 

mv2devnull

Golden Member
Apr 13, 2010
1,519
154
106
I changed ips to protect the innocent. Basically I just want traffic to stick to the interface that the client starts talking to via DNS.
That probably explains. Firewall is hardly the method for that. It does not tell the packets that they should use a particular interface and address. Firewall does block the "misrouted" traffic and confusion ensues.

Btw,
Code:
iptables -v -n --lin -L
shows statistics, i.e. which rules do match. That is what I check first, even before adding LOG rules.

'tcpdump' or similar is nice too, showing what kind of packets do appear.


What really might cause trouble is the two addresses on same subnet. I've never been exactly sure on how source routing behaves in that. Actually, why filter by interface at all? Just make sure that replies have the right IP. SNAT might help, if basic routing fails.


You did mention vlans. Aren't they separate subnets? If you had tagged vlan traffic, then you would have interfaces for each vlan, clear routing and filtering.


Edit:
While there is no routing (as in gateway / forward) on web-server listening on the machine, there is still routing. Incoming packets are routed to INPUT chain, and outgoing replies are routed after leaving the OUTPUT chain. That last bit is where the "magick" must happen.
 
Last edited:

KillerBee

Golden Member
Jul 2, 2010
1,750
82
91
I might give up on this and just move the less secure web traffic to another server. I was just trying to centralize certs and connect to the local mySQL server....

That just seems easier than rewriting all my other iptables entries to try to fix the 6 entries I need for these web servers. :p


Awww- hate to see you give up so quickly
Comeon how about some troubleshooting info we can use to help fix it- like what was the eth0 error? :)

-or at least post the final fix that worked - we need closure dammit :p
 
Last edited:

Scarpozzi

Lifer
Jun 13, 2000
26,391
1,780
126
Awww- hate to see you give up so quickly
Comeon how about some troubleshooting info we can use to help fix it- like what was the eth0 error? :)

-or at least post the final fix that worked - we need closure dammit :p

I can *work* on it, but need a quick fix for now and have other options short-term. I really do want to consolidate. I'm going to go ahead and migrate the files/apache configs to another box and setup my database connection....then I'll do some dns trickery and have a testing ground to keep hammering away at it. I've not had to play around much with iptables and 2 interfaces so this is good practice. I may see about saving my config and see how one of the wizards sets rules via a gui it'd be quicker than wading through all the linux firewall gateway docs that I keep finding.