Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I've been Googling about port forwarding iptables and even though there's result and I've applied it in my script, I can't make iptables forwading request to another machine so I decided to ask help.
eth0 is my Internet Interface (1.2.3.4 is the public ip)
eth1 is my Lan Interface
eth2 is my DMZ Interface
My Apache test server is 10.0.1.150
Below is my script:
Quote:
$iptables -F INPUT
$iptables -F OUTPUT
$iptables -P INPUT DROP
$iptables -P OUTPUT ACCEPT
$iptables -F FORWARD
$iptables -F -t nat
$iptables -P FORWARD DROP
$iptables -A FORWARD -i eth1 -j ACCEPT
$iptables -A INPUT -i eth1 -j ACCEPT
$iptables -A OUTPUT -o eth1 -j ACCEPT
$iptables -A FORWARD -i eth2 -j ACCEPT
$iptables -A INPUT -i eth2 -j ACCEPT
$iptables -A OUTPUT -o eth2 -j ACCEPT
$iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
$iptables -t nat -A POSTROUTING -s 0.0.0.0/0 -o eth0 -j SNAT --to-source 1.2.3.4
$iptables -t nat -A POSTROUTING -s 10.0.1.0/24 -o eth2 -j MASQUERADE
$iptables -A INPUT -i lo -j ACCEPT
$iptables -A OUTPUT -o lo -j ACCEPT
$iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
$iptables -I FORWARD -i eth1 -p tcp -m multiport --dport 0:79 -j REJECT
$iptables -I FORWARD -i eth1 -p tcp -m multiport --dport 81:65535 -j REJECT
$iptables -I FORWARD -i eth1 -o eth2 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
$iptables -A OUTPUT -p icmp -m state --state NEW -j ACCEPT
$iptables -A INPUT -p icmp -m state --state ESTABLISHED,RELATED -j ACCEPT
$iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/s -i eth0 -j ACCEPT
$iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j REDIRECT --to-port 8080
$iptables -A INPUT -p tcp -i eth0 --dport 3500 -j ACCEPT
$iptables -A INPUT -p tcp -i eth0 --dport 80 -j ACCEPT
$iptables -I FORWARD -i eth0 -p tcp -m state --state NEW -d 10.0.1.150 --dport 80 -j ACCEPT
$iptables -t nat -I PREROUTING -i eth0 -p tcp -d 1.2.3.4 --dport 80 -j DNAT --to-destination 10.0.1.150:80
$iptables -A INPUT -i eth0 -p tcp -m limit --limit 1/s --dport 0:65535 -j LOG --log-prefix "tcp connection: "
$iptables -A INPUT -i eth0 -p udp -m limit --limit 1/s --dport 0:65535 -j LOG --log-prefix "udp connection: "
$iptables -A INPUT -i eth0 -p tcp --dport 0:65535 -j DROP
$iptables -A INPUT -i eth0 -p udp --dport 0:65535 -j DROP
Looks to me like it should work as it is. Maybe place a LOG rule at the end of the FORWARD chain so we can see if your test packet is getting filtered there (and if so, what the packet's headers look like)?
Code:
iptables -A FORWARD -j LOG --log-prefix "FORWARD DROP: "
With these types of issues, it's also a good idea to post the output of:
place a LOG rule at the end of the FORWARD chain so we can see if your test packet is getting filtered there
I put $iptables -A FORWARD -j LOG --log-prefix "FORWARD DROP: " but doesn't see any packets on syslog. All I can see is the "tcp connection:" which came from limit.
Quote:
With these types of issues, it's also a good idea to post the output of:
Quote:
[root@test ~]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
202.1.0.24 0.0.0.0 255.255.255.192 U 0 0 0 eth0
10.0.1.0 10.0.1.1 255.255.255.0 UG 0 0 0 eth1
10.0.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth2
10.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 eth2
0.0.0.0 202.1.0.1 0.0.0.0 UG 0 0 0 eth0
202.1.0.24 is just a sample ip and 202.1.0.1 is just a sample gw from the isp.
I tried to install http and remove lines related to port 80 interface eth0, run script and I can see apache.
So probably culprit is somewhere on the script or routing issue but is it possible routing issue even I could telnet the service (http)??? Server can connect to the private lan server where apache is installed.
[root@test ~]# ip route
202.80.2.0/26 dev eth0 proto kernel scope link src 202.80.2.57
10.0.1.0/24 dev eth1 proto kernel scope link src 10.0.1.210
192.168.1.0/24 via 10.0.1.151 dev eth1
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.2
169.254.0.0/16 dev eth2 scope link
10.0.0.0/8 dev eth2 proto kernel scope link src 10.4.0.100
default via 202.84.20.3 dev eth0
iptables-save
Quote:
[root@test ~]# iptables-save
# Generated by iptables-save v1.3.5 on Wed Jun 9 08:46:33 2010
*nat
:PREROUTING ACCEPT [26774:2237252]
:POSTROUTING ACCEPT [3584:431485]
:OUTPUT ACCEPT [3717:440300]
-A PREROUTING -s 192.168.1.200 -i eth1 -p tcp -m tcp --dport 80 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A PREROUTING -d 202.80.2.57 -i eth0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 10.0.1.150:80
-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8080
-A POSTROUTING -o eth0 -j SNAT --to-source 202.80.2.57
-A POSTROUTING -s 10.0.1.0/255.255.255.0 -o eth2 -j MASQUERADE
COMMIT
# Completed on Wed Jun 9 08:46:33 2010
# Generated by iptables-save v1.3.5 on Wed Jun 9 08:46:33 2010
*filter
:INPUT DROP [17:1156]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [1281:194076]
-A INPUT -i eth1 -j ACCEPT
-A INPUT -i eth2 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i eth0 -p icmp -m icmp --icmp-type 8 -m limit --limit 1/sec -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 3500 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -i eth0 -p tcp -m limit --limit 1/sec -m tcp -j LOG --log-prefix "tcp connection: "
-A INPUT -i eth0 -p udp -m limit --limit 1/sec -m udp -j LOG --log-prefix "udp connection: "
-A INPUT -i eth0 -p tcp -m tcp -j DROP
-A INPUT -i eth0 -p udp -m udp -j DROP
-A FORWARD -d 10.0.1.150 -i eth0 -o eth1 -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
-A FORWARD -i eth1 -p tcp -m multiport --dports 81:65535 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -i eth1 -p tcp -m multiport --dports 0:79 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -i eth1 -j ACCEPT
-A FORWARD -i eth2 -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -j LOG --log-prefix "FORWARD DROP: "
-A OUTPUT -o eth1 -j ACCEPT
-A OUTPUT -o eth2 -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -p icmp -m state --state NEW -j ACCEPT
COMMIT
# Completed on Wed Jun 9 08:46:33 2010
Does it make sense if I know I can telnet to the DMZ server on the port I'm trying to forward, do I need to think that problem might still be on the network side? Even if I can trace route succesfully to the dmz server?
Quote:
[root@test rc.d]# traceroute 10.0.1.150
traceroute to 10.0.1.150 (10.0.1.150), 30 hops max, 40 byte packets
1 10.0.1.1 (10.0.1.1) 7.825 ms 7.788 ms 7.842 ms
2 10.0.1.150 (10.0.1.150) 10.501 ms 10.578 ms 1.918 ms
The 'multiport' module is only for non-sequential numbers (like 25,110,143.) If you are doing a continuous range, it works with the standard '--dport' match. So replace those two rules with this one:
Hrmm... It will take me to long to do this line by line, here is my suggestion. Test it to check that it works and ask if you have any questions:
Code:
#
# Generated by SuperJediWombat v1.3.3.7 on Thu Jun 10 22:40:16 2010
#
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i eth1 -j ACCEPT
-A INPUT -i eth2 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i eth0 -p icmp -m icmp --icmp-type 8 -m limit --limit 3/sec -j ACCEPT
-A INPUT -i eth0 -p icmp -m icmp --icmp-type 8 -j DROP
-A INPUT -i eth0 -p tcp -m tcp --dport 3500 -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth1 -o eth0 -j ACCEPT
-A FORWARD -i eth2 -o eth0 -j ACCEPT
-A FORWARD -i eth1 -o eth2 -p tcp -s 10.0.1.156 -d 10.4.0.0/24 -j ACCEPT
-A FORWARD -o eth0 -p tcp --dport 80 -j ACCEPT
-A FORWARD ! -i eth0 -p tcp -j REJECT --reject-with icmp-port-unreachable
COMMIT
*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A PREROUTING -i eth0 -p tcp -m tcp -d 1.2.3.4 --dport 80 -j DNAT --to-destination 10.4.0.236:80
-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8080
-A POSTROUTING -o eth0 -j SNAT --to-source 1.2.3.4
-A POSTROUTING -o eth2 -j MASQUERADE
COMMIT
Most of what I cut out was redundant. Covered by either your default policy (drop, except for outbound) or by other rules.
You need to remember that packets that are being routed are covered by the FORWARD chain. INPUT and OUTPUT are only for packets that are addressed directly to or from the firewall itself. If you don't understand that you really need to ask for more clarification.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.