Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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).

share|improve this question
    
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? –  MadHatter Aug 6 at 7:08
    
A client outside the firewall box, connecting via eth0. Connection via the firewall box itself works as expected. –  juansta Aug 6 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. –  MadHatter Aug 6 at 7:17

1 Answer 1

up vote 5 down vote accepted

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.

share|improve this answer
    
you were right, there was no route for my server behind the firewall. –  juansta Aug 7 at 1:02

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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