4

I am trying to remove a router from our product and replacing all its functionality with the use of iptables.

The system is required to perform general traffic control as well as forwarding data to specific servers sitting behind the LAN. Current setup is -

  • eth0 - External
  • eth1 - Internal
  • eth2 - Internal
  • eth3 - Internal

eth0 gets an IP via DHCP.

eth1, eth2 and eth3 form part of a bridge (br0) which has a static address of 10.0.1.1.

There is a server sitting on 10.0.1.2 who needs to server HTTP and MySQL traffic. There is no guarantee where this server will be plugged into (eth1/2/3) but the IP is static.

I have tried to setup iptables rules, which seem to be easy to follow with only a single eth device, but I am getting tied up in knots when there is forwarding required.

This is what I have tried so far:

# clear and flush everything iptables -F iptables -X iptables -t nat -F iptables -t nat -X iptables -t mangle -F iptables -t mangle -X iptables -t raw -F iptables -t raw -X iptables -t security -F iptables -t security -X # DROP packets unless covered by rules iptables -P FORWARD DROP iptables -P INPUT DROP # No intention of filtering any outgoing traffic iptables -P OUTPUT ACCEPT # Handle our routing iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to 10.0.1.2:80 iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 3306 -j DNAT --to 10.0.1.2:3306 iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE # Input Chain iptables -A INPUT -i lo -j ACCEPT iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT iptables -A INPUT -i eth0 -p tcp --dport 22 -j ACCEPT # ssh iptables -A INPUT -s 10.0.1.2 -p tcp --dport 3306 -j ACCEPT # ssh # Forward Chain iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT iptables -A FORWARD -i eth0 -p tcp --dport 80 -d 10.0.1.2 -j ACCEPT iptables -A FORWARD -i eth0 -p tcp --dport 3306 -d 10.0.1.2 -j ACCEPT # enable ipv4 forwardning for the system echo 1 > /proc/sys/net/ipv4/ip_forward

This gives me the resulting chain/rule setup -

Chain INPUT (policy DROP 1 packets, 49948 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 1 52 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED 0 0 ACCEPT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 0 0 ACCEPT tcp -- * * 10.0.1.2 0.0.0.0/0 tcp dpt:3306 Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED 0 0 ACCEPT tcp -- eth0 * 0.0.0.0/0 10.0.1.2 tcp dpt:80 0 0 ACCEPT tcp -- eth0 * 0.0.0.0/0 10.0.1.2 tcp dpt:3306 Chain OUTPUT (policy ACCEPT 1 packets, 196 bytes) pkts bytes target prot opt in out source destination

However, I am unable to log into my internal MySQL server through a client connected via the external interface (outside firewall box).

I have read that packets only pass through each ONE chain (either INPUT/FORWARD/OUTPUT) but is this still the case here? Are my FORWARD packets, then to be handled again as INPUT on a separate interface?

Is there anything that stands out as wrong in any of the configuration above?

Configuration details -

Output of netstat -rn

From a client that I CAN connect from...

Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 10.0.0.139 0.0.0.0 UG 0 0 0 eth0 10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 10.0.1.0 0.0.0.0 255.255.255.0 U 0 0 0 br0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br0

Telnet connects as expected.

From a client that I CANNOT connect from...

Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 10.0.0.139 0.0.0.0 UG 0 0 0 eth0 10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 10.0.0.0 0.0.0.0 255.255.0.0 U 0 0 0 wlan0

Telnet just displays Trying 10.0.0.17... and never actually succeeds...

Network Description(s) -

10.0.0.0 is general office network, and the eth0 interface on the firewall box is connected here. Its IP address is currently 10.0.0.17...

10.0.1.0 is the network that is meant to be behind the firewall eth1/2/3.

I want to access servers that are behind the firewall by using IP address given to eth0 (10.0.0.17).

Improve this question
3
  • When you say "I am unable to log into my internal MySQL server through the external interface", where are you trying this from? A client outside the firewall box; or on the firewall box itself? Commented Aug 6, 2014 at 7:08
  • A client outside the firewall box, connecting via eth0. Connection via the firewall box itself works as expected. Commented Aug 6, 2014 at 7:15
  • 2
    OK, that knocks out potential failure mode 1. What do you mean by "I am unable to log in"? What happens when from that client you do telnet 10.0.1.2 3306? What is the output of netstat -rn on that client? You might want to edit the answers to that into your question; they will lose formatting in comments. Commented Aug 6, 2014 at 7:17

1 Answer 1

Reset to default
5

Since you list a client that can connect, there is nothing wrong with your iptables setup. That, however, is not the whole story: the clients must have a route to reach the server's forwarded address, and the server must have a route back, for the packets to get as far as the FORWARDing.

The client that works has some physical presence on the 10.0.1.0/24 network, and consequently a route thereto:

10.0.1.0 0.0.0.0 255.255.255.0 U 0 0 0 br0

The client that doesn't not only has no route to 10.0.1.0/24, but has a more general route to 10.0.0.0/16 sending traffic out its wireless card.

Now you haven't told us the geometry of the network that this is all happening in; from the confusion between /24 and /16 netmasks for overlapping space, I'm guessing it's all a bit confused (that's not a guarantee; there are legitimate reasons to do that, but hey're generally outnumbered by the foolish ones). In addition, the details of your network are only interesting to you.

But the upshot is that any client that wants to get as far as 10.0.1.2 must first of all have some idea how to get to 10.0.1.0/24, and it must moreover be a correct idea.

Fix the routing tables on your clients in a manner consonant with your network geometry, and everything should improve.

Improve this answer
1
  • you were right, there was no route for my server behind the firewall. Commented Aug 7, 2014 at 1:02

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.