0

I have multiple ethX interfaces.

  • eth0 is connected to the internet.
  • eth1 is connected to a trusted network.
  • eth2 is connected to a network I need to impose usage rules.

What I'd like to do is separate eth1 and eth2 into their own chains (trusted/untrusted) simply to maintain "easy on the eyes" rules.

:INPUT DROP
-A INPUT ! -i eth0 -j ACCEPT    # allows INPUT on traffic not internet based
... # More rules for eth0 allowing PING and shunting most everything else
-A INPUT -i eth1 -j trusted
-A INPUT -i eth2 -j untrusted

OUTPUT and FORWARD are currently set to ACCEPT due to the problems.

For the time being, eth1 is just jumping to chain masquerade which is perfectly fine for the moment, but the confusion lies as to how to manipulate eth2 as it hasn't panned out too well with my attempts.

My guess was to list all of the ALLOWED ports/protocols, but so far it's not working as devices connected through eth2 cannot reach anything, not even the firewall server's DNS/DHCP.

:untrusted
-A untrusted -i eth2 -p tcp -m tcp --dport 80 -j ACCEPT

What I need is basically a set of rules which "say" the following:

  1. If outgoing internet traffic on eth0 is not PING, DROP
  2. If eth1 goes out to internet (eth0), accept it
  3. If eth2 goes out to internet on TCP port 80, accept it, drop everything else.
  4. To GO out to internet, use masquerade through eth0

Any thoughts/suggestions would be truly appreciated!

6
  • @jasonwryan: Thanks for the edit! I'm running on a kiosk with Fox21 and I don't have much option to format nicely/cleanly save for bold and have to use HTML breaks just to implement line feeds. – T.J. Feb 27 '15 at 8:00
  • Wow: that is dedication! :) – jasonwryan Feb 27 '15 at 8:02
  • LOL - no, not dedication... it's a custom kernel/init where I simply haven't updated the repository in quite some time! :) HOWEVER, I just tinkered with block quotes and the likes and believe I have things down-pat manually (ie: 4 spaces after an empty line starts a code block, etc.) – T.J. Feb 27 '15 at 8:06
  • -A INPUT ! eth0 -j ACCEPT, isn't that missing a -i before the eth0? Apart from that: untrusted is already just for traffic coming in from eth2, so the -A untrusted -i eth0 ... makes no sense. – wurtel Feb 27 '15 at 9:47
  • @wurtel Sorry, you are correct, the "-i" is missing (a typo HERE on my part since I couldn't copy/paste at the time.) Regarding -A untrusted as the default policy is to DROP, the additional rules were intended for ACCEPT (thus ports not listed would drop) however I believe I typed in eth0 instead of eth2 where technically neither are "required" as I could have left the -i ethX out completely. – T.J. Feb 27 '15 at 10:59
0
-A OUTPUT -o eth0 -p icmp --icmp-type ping -j ACCEPT
-A OUTPUT -o eth0 -j DROP

-A FORWARD -i eth1 -o eth0 -j ACCEPT
-A FORWARD -i eth0 -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT

-A FORWARD -i eth2 -o eth0 -p tcp --dport 80 -j ACCEPT
-A FORWARD -i eth2 -o eth0 -j DROP
-A FORWARD -i eth0 -o eth2 -m state --state ESTABLISHED,RELATED -j ACCEPT

*nat
-A POSTROUTING -s 192.168.2.0/24 -o eth0 -j MASQUERADE

Change the 192.168.2.0/24 to the network on eth2 in the last line; that's so that just packets originating on the eth2 network will be masqueraded.

I also prefer to explicitly add a rule to drop packets at the end of a chain instead of relying on the policy.

This should cover the points in your question.

6
  • Thank you for the post and for not saying "are you stupid?" with my 3am less than half-awake request #1 ("output of PING" instead of input) :) I must have done something wrong with routing or the likes... save for the network being used in your masquerade (I just used the interface) and the explicit drops, my logic was the same as yours. (Another reason I wanted to divide this into separate chains.) If eth1 and eth2 were on the same subnet in the example above, would that pose any foreseen issues? (10.x.x.x) – T.J. Feb 27 '15 at 16:16
  • Thank you again. For what ever reason this particular layout isn't working out well and I can't find anything erroneous. eth2 is connected to the WAN side of a wireless router. With the firewall in place, the router calls the server's DHCP (and gets through) but for what ever reason the response acts as though it never makes it back to the router. The server shows ongoing request/response broadcasts but the router just keeps requesting. When I plug both in using a switch, it goes through perfectly. Any thoughts? (UDP 67-69 are open) – T.J. Feb 28 '15 at 11:24
  • If eth1 and eth2 are on the same subnet, then routing towards that subnet will probably be wrong for one of the devices... never a good idea. Why not just connect one of the LAN ports of the wireless router to eth2 and use it as an access point... I'm not a fan of double NAT. – wurtel Mar 2 '15 at 11:08
  • I'm not a fan, either, and that's what I've had to do in the past. The routers require WAN side for things as simple as NTP... (D-Link and Tenda both seem to have a lease quirk in this regard). At the moment I'm forced to do this (AP instead of router) as the routers are seemingly dropping the reply broadcast from DHCP - nothing in logs from either end showing anything out of the ordinary. The local network is 10.x.x.x and the routers (their own lan side) are 192.168.x.1. Now the ODD part is when plugging the router (WAN) into a managed switch... the process goes through fine. – T.J. Mar 3 '15 at 15:38
  • No chance of putting openwrt on the router? Seems like that would be the best solution, firewall it at the source. – wurtel Mar 3 '15 at 15:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.