Topic: IP forwarding problem

The content of this topic has been archived on 13 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Page 1 of 1

Post #1

sbar

17 Oct 2011, 21:03

Hi there.

Previously I was using D-Link DIR-620 with its original firmware. There was a problem in the web-interface: I couldn't configure port forwarding using it, that's why those commands helped me (192.168.1.2 — internal server, 77.77.77.77 — external IP):

iptables -t nat -A PREROUTING -p tcp -i br0 -d 77.77.77.77 --dport 21 -j DNAT --to 192.168.1.2:21
iptables -A FORWARD -p tcp -i br0 -d 192.168.1.2 --dport 21 -j ACCEPT

And it was working: if I try to connect from the outside to 77.77.77.77:21, I reach the internal 192.168.1.2:21 ftp-server.

Now I've got TP-Link MR3420. It runs OpenWrt via this doc.

I've got this ifconfig output:

br-lan    Link encap:Ethernet  HWaddr XX:XX:XX:XX:XX:XX
          inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::f6ec:38ff:feab:427d/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:83903 errors:0 dropped:0 overruns:0 frame:0
          TX packets:147151 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:5172397 (4.9 MiB)  TX bytes:156452191 (149.2 MiB)

eth0      Link encap:Ethernet  HWaddr XX:XX:XX:XX:XX:XX
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1177 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1295 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:303415 (296.3 KiB)  TX bytes:121845 (118.9 KiB)
          Interrupt:5

eth1      Link encap:Ethernet  HWaddr XX:XX:XX:XX:XX:XX
          inet addr:77.77.77.77  Bcast:XX.XX.XX.XX  Mask:XXX.XXX.XXX.XXX
          inet6 addr: xxxx::xxxx:xxxx:xxxx:xxxx/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:196816 errors:0 dropped:0 overruns:0 frame:0
          TX packets:75108 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:160544778 (153.1 MiB)  TX bytes:5708921 (5.4 MiB)
          Interrupt:4

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:94 errors:0 dropped:0 overruns:0 frame:0
          TX packets:94 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:8373 (8.1 KiB)  TX bytes:8373 (8.1 KiB)

mon.wlan0 Link encap:UNSPEC  HWaddr XX-XX-XX-XX-XX-XX-XX-XX-XX-XX-XX-XX-XX-XX-XX-XX  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:162 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000

          RX bytes:11173 (10.9 KiB)  TX bytes:0 (0.0 B)

wlan0     Link encap:Ethernet  HWaddr XX:XX:XX:XX:XX:XX
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:85049 errors:0 dropped:0 overruns:0 frame:0
          TX packets:148133 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:6458396 (6.1 MiB)  TX bytes:159699844 (152.3 MiB)

I've tried different configurations using /etc/config/firewall, but I've got always "21/tcp closed ftp" nmap output. So I don't trust this firewall script 'cause I see a lot of errors, when I restart it. Here they are with iptables settings and sysctl: http://dumpz.org/93721/nixtext/

So, it doesn't make any sense anyway. I want to configure iptables manually.
I reset iptables settings and simply set my own rules:

iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
iptables -t nat -A PREROUTING -p tcp -i br-lan -d 77.77.77.77 --dport 21 -j DNAT --to 192.168.1.2:21
iptables -A FORWARD -p tcp -i br-lan -d 192.168.1.2 --dport 21 -j ACCEPT

Now, if I nmap my external IP — I get this: "21/tcp filtered ftp"

Any suggestions? Thank you!

Post #2

jow

17 Oct 2011, 21:54

The firewall script errors seem to be caused by a broken shell. As for your manual rules; make sure the raw table is empty, check whether your ftp service is indeed listening and make sure your rules are actually reached.

Post #3

sbar

18 Oct 2011, 19:21

jow wrote:

make sure the raw table is empty

Thank you. I see this after flushing iptables rules:

root@router ~ # iptables -t raw --list
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
zone_lan_notrack  all  --  anywhere             anywhere            
zone_wan_notrack  all  --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain zone_lan_notrack (1 references)
target     prot opt source               destination         

Chain zone_wan_notrack (1 references)
target     prot opt source               destination

So I flushed it too (how to flush iptables completely, BTW?)

root@router ~ # iptables -t raw -F
root@router ~ # iptables -t raw -X
root@router ~ # iptables -t raw -Z
root@router ~ # iptables -t raw --list
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
root@router ~ #

Nothing changed, I still get "filtered" after applying

iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
iptables -t nat -A PREROUTING -p tcp -i br-lan -d 77.77.77.77 --dport 21 -j DNAT --to 192.168.1.2:21
iptables -A FORWARD -p tcp -i br-lan -d 192.168.1.2 --dport 21 -j ACCEPT

jow wrote:

check whether your ftp service is indeed listening

It does

sbar@router ~ $ nmap -p21 192.168.1.2 | grep '21/tcp'
21/tcp open  ftp
sbar@router ~ $ lftp 192.168.1.2
lftp 192.168.1.2:~> ls              
drwxr-xr-x    2 1000     1000         4096 Mar 25  2011 distfiles
drwxr-xr-x    2 0        0            4096 Apr 13  2011 gentoo
drwxrwxrwx    2 0        0            4096 Jul 29 14:41 incoming
drwxr-xr-x    4 1000     1000         4096 Jul 30 19:04 tmp
lftp 192.168.1.2:/>

The same thing from other local computer — it can connect to 192.168.1.2:21.

jow wrote:

make sure your rules are actually reached.

root@router ~ # cat iptables-reset.sh
#!/bin/sh

iptables -F
iptables -X
iptables -Z
iptables -t mangle -F
iptables -t mangle -X
iptables -t mangle -Z
iptables -t nat -F
iptables -t nat -X
iptables -t nat -Z
iptables -t raw -F
iptables -t raw -X
iptables -t raw -Z
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
root@router ~ # ./iptables-reset.sh
root@router ~ # iptables-save | egrep -v '^#' > before.txt
root@router ~ # iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
root@router ~ # iptables -t nat -A PREROUTING -p tcp -i br-lan -d 77.77.77.77 --dport 21 -j DNAT --to 192.168.1.2:21
root@router ~ # iptables -A FORWARD -p tcp -i br-lan -d 192.168.1.2 --dport 21 -j ACCEPT
root@router ~ # iptables-save | egrep -v '^#' > after.txt
root@router ~ # diff -u before.txt after.txt
--- before.txt  2011-10-18 21:51:26.197951002 +0400
+++ after.txt   2011-10-18 21:51:47.177951002 +0400
@@ -1,22 +1,25 @@
 *nat
-:PREROUTING ACCEPT [21:1220]
-:INPUT ACCEPT [11:620]
-:OUTPUT ACCEPT [9:544]
-:POSTROUTING ACCEPT [19:1144]
+:PREROUTING ACCEPT [0:0]
+:INPUT ACCEPT [0:0]
+:OUTPUT ACCEPT [0:0]
+:POSTROUTING ACCEPT [0:0]
+-A PREROUTING -d 77.77.77.77/32 -i br-lan -p tcp -m tcp --dport 21 -j DNAT --to-des
tination 192.168.1.2:21
+-A POSTROUTING -o eth1 -j MASQUERADE
 COMMIT
 *raw

-:PREROUTING ACCEPT [384:30386]
-:OUTPUT ACCEPT [178:16819]
+:PREROUTING ACCEPT [509:41383]
+:OUTPUT ACCEPT [245:22891]
 COMMIT
 *mangle
-:PREROUTING ACCEPT [384:30386]
-:INPUT ACCEPT [307:21166]
-:FORWARD ACCEPT [77:9220]
-:OUTPUT ACCEPT [178:16819]
-:POSTROUTING ACCEPT [255:26039]
+:PREROUTING ACCEPT [509:41383]
+:INPUT ACCEPT [415:28558]
+:FORWARD ACCEPT [94:12825]
+:OUTPUT ACCEPT [245:22891]
+:POSTROUTING ACCEPT [339:35716]
 COMMIT
 *filter
-:INPUT ACCEPT [307:21166]
-:FORWARD ACCEPT [77:9220]
-:OUTPUT ACCEPT [178:16819]
+:INPUT ACCEPT [54:3504]

+:FORWARD ACCEPT [9:1967]
+:OUTPUT ACCEPT [30:2752]
+-A FORWARD -d 192.168.1.2/32 -i br-lan -p tcp -m tcp --dport 21 -j ACCEPT
 COMMIT

Complete before and after rules apply iptables-save output; iptables -L -nvt nat output.

Please tell me if I can show something more to help with understanding of the problem. Thank you.

Post #4

sbar

21 Oct 2011, 18:18

Resolved. That problem was 'cause of this parameter:

net.bridge.bridge-nf-call-iptables=0

When it's 1 — everything works.

Post #5

jow

21 Oct 2011, 18:25

That now means that any bridge traffic is funneled through iptables, that can degrade performance quite a bit.

Post #6

sbar

21 Oct 2011, 19:13

I was mistaken

I've got another kind of problem now: I can connect from a local computer using an external IP, but I can't connect using external computer to the same IP.
Also, I can't even connect from the same server using an external IP (but local IPs work).

nmap -p21 77.77.77.77 from server says "filtered", but from any other internal computer — "open". (I can't try it from the external computer, but I think the same "filtered" there will be).

Server's firewall is not configured ("iptables -L -nvt nat" says a default output).

Any suggestions?
Thank you.

(Last edited by sbar on 21 Oct 2011, 19:20)

Post #7

jow

21 Oct 2011, 19:22

From the firewalls point of view, accessing the own external ip from within the lan is something completely different compared to accessing the external from an external host. You really should test your rules with an online port scan service or something.

Post #8

sbar

21 Oct 2011, 21:06

jow wrote:

You really should test your rules with an online port scan service or something.

I've tried this one—it says "closed".

The same rules worked with another router. Server's rules are still unchanged.

(Last edited by sbar on 21 Oct 2011, 21:08)

Post #9

sbar

29 Oct 2011, 16:01

Removing "-i br-lan" resolved this problem.

Post #10

codeblue

17 Apr 2012, 11:36

jow wrote:

The firewall script errors seem to be caused by a broken shell. As for your manual rules; make sure the raw table is empty, check whether your ftp service is indeed listening and make sure your rules are actually reached.

YEP, just make sure that /bin/sh is a symbol of /bin/busybux ,but not bash or sth.

The discussion might have continued from here.

Page 1 of 1