Confounding problem about iptables











up vote
1
down vote

favorite












Recently, I used wget to try to pull down some packages through port 80. It is blocked by iptable (after the service iptables stops, wget can download the packages). Could anybody help me analyze my iptable rules?



I think I've opened all the ports for local IPs (192.168.0.0/16, 10.0.0.0/8), so why is it blocked?



My computer's IP is 192.168.1.168.



If I prepare a web server at 192.168.1.170, I can download the page from 192.168.1.170.



table:filter
Chain INPUT (policy DROP)
num target prot opt source destination
1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
2 ACCEPT all -- 0.0.0.0/8 0.0.0.0/0
3 ACCEPT all -- 10.0.0.0/8 0.0.0.0/0
4 ACCEPT all -- 127.0.0.0/8 0.0.0.0/0
5 ACCEPT all -- 169.254.0.0/16 0.0.0.0/0
6 ACCEPT all -- 172.16.0.0/12 0.0.0.0/0
7 ACCEPT all -- 192.168.0.0/16 0.0.0.0/0
8 ACCEPT all -- 224.0.0.0/4 0.0.0.0/0
9 ACCEPT all -- 240.0.0.0/4 0.0.0.0/0
10 ACCEPT all -- 144.168.60.32 0.0.0.0/0
11 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:21701 state NEW,ESTABLISHED
12 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:21701 state ESTABLISHED
13 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:26941 state ESTABLISHED
14 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:21713 state ESTABLISHED
15 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:21715 state ESTABLISHED
16 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:21714 state ESTABLISHED
17 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:80 state ESTABLISHED
18 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 state NEW,ESTABLISHED
19 ACCEPT tcp -- 23.105.194.21 0.0.0.0/0 tcp spt:8170 state ESTABLISHED
20 ACCEPT udp -- 114.114.114.114 0.0.0.0/0 udp spt:53 dpts:1024:65535
21 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 8
22 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 11
23 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 0
24 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:8080 state NEW,ESTABLISHED
25 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp spt:123

Chain FORWARD (policy DROP)
num target prot opt source destination
2 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
3 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
4 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0

Chain OUTPUT (policy DROP)
num target prot opt source destination
1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
2 ACCEPT all -- 0.0.0.0/0 0.0.0.0/8
3 ACCEPT all -- 0.0.0.0/0 10.0.0.0/8
4 ACCEPT all -- 0.0.0.0/0 127.0.0.0/8
5 ACCEPT all -- 0.0.0.0/0 169.254.0.0/16
6 ACCEPT all -- 0.0.0.0/0 172.16.0.0/12
7 ACCEPT all -- 0.0.0.0/0 192.168.0.0/16
8 ACCEPT all -- 0.0.0.0/0 208.0.0.0/4
9 ACCEPT all -- 0.0.0.0/0 240.0.0.0/4
10 ACCEPT all -- 0.0.0.0/0 144.168.60.32
11 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:21701 state ESTABLISHED
12 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:21701 state NEW,ESTABLISHED
13 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:26941 state NEW,ESTABLISHED
14 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:21713 state NEW,ESTABLISHED
15 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:21715 state NEW,ESTABLISHED
16 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:21714 state NEW,ESTABLISHED
17 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 state NEW,ESTABLISHED
18 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:80 state ESTABLISHED
19 ACCEPT tcp -- 0.0.0.0/0 23.105.194.26 tcp dpt:8170 state NEW,ESTABLISHED
20 ACCEPT udp -- 0.0.0.0/0 114.114.114.114 udp spts:1024:65535 dpt:53
21 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 8
22 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:8080 state ESTABLISHED
23 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:8080 state ESTABLISHED
24 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:123

table:nat
Chain PREROUTING (policy ACCEPT)
num target prot opt source destination
1 DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 to:172.17.42.1:80

Chain POSTROUTING (policy ACCEPT)
num target prot opt source destination
1 MASQUERADE all -- 172.17.0.0/16 0.0.0.0/0
2 MASQUERADE tcp -- 172.17.0.3 172.17.0.3 tcp dpt:80
3 MASQUERADE tcp -- 172.17.0.3 172.17.0.3 tcp dpt:22
4 MASQUERADE tcp -- 172.17.0.3 172.17.0.3 tcp dpt:21

Chain OUTPUT (policy ACCEPT)
num target prot opt source destination









share|improve this question




























    up vote
    1
    down vote

    favorite












    Recently, I used wget to try to pull down some packages through port 80. It is blocked by iptable (after the service iptables stops, wget can download the packages). Could anybody help me analyze my iptable rules?



    I think I've opened all the ports for local IPs (192.168.0.0/16, 10.0.0.0/8), so why is it blocked?



    My computer's IP is 192.168.1.168.



    If I prepare a web server at 192.168.1.170, I can download the page from 192.168.1.170.



    table:filter
    Chain INPUT (policy DROP)
    num target prot opt source destination
    1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
    2 ACCEPT all -- 0.0.0.0/8 0.0.0.0/0
    3 ACCEPT all -- 10.0.0.0/8 0.0.0.0/0
    4 ACCEPT all -- 127.0.0.0/8 0.0.0.0/0
    5 ACCEPT all -- 169.254.0.0/16 0.0.0.0/0
    6 ACCEPT all -- 172.16.0.0/12 0.0.0.0/0
    7 ACCEPT all -- 192.168.0.0/16 0.0.0.0/0
    8 ACCEPT all -- 224.0.0.0/4 0.0.0.0/0
    9 ACCEPT all -- 240.0.0.0/4 0.0.0.0/0
    10 ACCEPT all -- 144.168.60.32 0.0.0.0/0
    11 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:21701 state NEW,ESTABLISHED
    12 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:21701 state ESTABLISHED
    13 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:26941 state ESTABLISHED
    14 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:21713 state ESTABLISHED
    15 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:21715 state ESTABLISHED
    16 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:21714 state ESTABLISHED
    17 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:80 state ESTABLISHED
    18 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 state NEW,ESTABLISHED
    19 ACCEPT tcp -- 23.105.194.21 0.0.0.0/0 tcp spt:8170 state ESTABLISHED
    20 ACCEPT udp -- 114.114.114.114 0.0.0.0/0 udp spt:53 dpts:1024:65535
    21 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 8
    22 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 11
    23 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 0
    24 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:8080 state NEW,ESTABLISHED
    25 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp spt:123

    Chain FORWARD (policy DROP)
    num target prot opt source destination
    2 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
    3 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
    4 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0

    Chain OUTPUT (policy DROP)
    num target prot opt source destination
    1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
    2 ACCEPT all -- 0.0.0.0/0 0.0.0.0/8
    3 ACCEPT all -- 0.0.0.0/0 10.0.0.0/8
    4 ACCEPT all -- 0.0.0.0/0 127.0.0.0/8
    5 ACCEPT all -- 0.0.0.0/0 169.254.0.0/16
    6 ACCEPT all -- 0.0.0.0/0 172.16.0.0/12
    7 ACCEPT all -- 0.0.0.0/0 192.168.0.0/16
    8 ACCEPT all -- 0.0.0.0/0 208.0.0.0/4
    9 ACCEPT all -- 0.0.0.0/0 240.0.0.0/4
    10 ACCEPT all -- 0.0.0.0/0 144.168.60.32
    11 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:21701 state ESTABLISHED
    12 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:21701 state NEW,ESTABLISHED
    13 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:26941 state NEW,ESTABLISHED
    14 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:21713 state NEW,ESTABLISHED
    15 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:21715 state NEW,ESTABLISHED
    16 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:21714 state NEW,ESTABLISHED
    17 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 state NEW,ESTABLISHED
    18 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:80 state ESTABLISHED
    19 ACCEPT tcp -- 0.0.0.0/0 23.105.194.26 tcp dpt:8170 state NEW,ESTABLISHED
    20 ACCEPT udp -- 0.0.0.0/0 114.114.114.114 udp spts:1024:65535 dpt:53
    21 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 8
    22 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:8080 state ESTABLISHED
    23 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:8080 state ESTABLISHED
    24 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:123

    table:nat
    Chain PREROUTING (policy ACCEPT)
    num target prot opt source destination
    1 DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 to:172.17.42.1:80

    Chain POSTROUTING (policy ACCEPT)
    num target prot opt source destination
    1 MASQUERADE all -- 172.17.0.0/16 0.0.0.0/0
    2 MASQUERADE tcp -- 172.17.0.3 172.17.0.3 tcp dpt:80
    3 MASQUERADE tcp -- 172.17.0.3 172.17.0.3 tcp dpt:22
    4 MASQUERADE tcp -- 172.17.0.3 172.17.0.3 tcp dpt:21

    Chain OUTPUT (policy ACCEPT)
    num target prot opt source destination









    share|improve this question


























      up vote
      1
      down vote

      favorite









      up vote
      1
      down vote

      favorite











      Recently, I used wget to try to pull down some packages through port 80. It is blocked by iptable (after the service iptables stops, wget can download the packages). Could anybody help me analyze my iptable rules?



      I think I've opened all the ports for local IPs (192.168.0.0/16, 10.0.0.0/8), so why is it blocked?



      My computer's IP is 192.168.1.168.



      If I prepare a web server at 192.168.1.170, I can download the page from 192.168.1.170.



      table:filter
      Chain INPUT (policy DROP)
      num target prot opt source destination
      1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
      2 ACCEPT all -- 0.0.0.0/8 0.0.0.0/0
      3 ACCEPT all -- 10.0.0.0/8 0.0.0.0/0
      4 ACCEPT all -- 127.0.0.0/8 0.0.0.0/0
      5 ACCEPT all -- 169.254.0.0/16 0.0.0.0/0
      6 ACCEPT all -- 172.16.0.0/12 0.0.0.0/0
      7 ACCEPT all -- 192.168.0.0/16 0.0.0.0/0
      8 ACCEPT all -- 224.0.0.0/4 0.0.0.0/0
      9 ACCEPT all -- 240.0.0.0/4 0.0.0.0/0
      10 ACCEPT all -- 144.168.60.32 0.0.0.0/0
      11 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:21701 state NEW,ESTABLISHED
      12 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:21701 state ESTABLISHED
      13 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:26941 state ESTABLISHED
      14 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:21713 state ESTABLISHED
      15 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:21715 state ESTABLISHED
      16 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:21714 state ESTABLISHED
      17 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:80 state ESTABLISHED
      18 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 state NEW,ESTABLISHED
      19 ACCEPT tcp -- 23.105.194.21 0.0.0.0/0 tcp spt:8170 state ESTABLISHED
      20 ACCEPT udp -- 114.114.114.114 0.0.0.0/0 udp spt:53 dpts:1024:65535
      21 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 8
      22 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 11
      23 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 0
      24 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:8080 state NEW,ESTABLISHED
      25 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp spt:123

      Chain FORWARD (policy DROP)
      num target prot opt source destination
      2 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
      3 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
      4 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0

      Chain OUTPUT (policy DROP)
      num target prot opt source destination
      1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
      2 ACCEPT all -- 0.0.0.0/0 0.0.0.0/8
      3 ACCEPT all -- 0.0.0.0/0 10.0.0.0/8
      4 ACCEPT all -- 0.0.0.0/0 127.0.0.0/8
      5 ACCEPT all -- 0.0.0.0/0 169.254.0.0/16
      6 ACCEPT all -- 0.0.0.0/0 172.16.0.0/12
      7 ACCEPT all -- 0.0.0.0/0 192.168.0.0/16
      8 ACCEPT all -- 0.0.0.0/0 208.0.0.0/4
      9 ACCEPT all -- 0.0.0.0/0 240.0.0.0/4
      10 ACCEPT all -- 0.0.0.0/0 144.168.60.32
      11 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:21701 state ESTABLISHED
      12 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:21701 state NEW,ESTABLISHED
      13 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:26941 state NEW,ESTABLISHED
      14 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:21713 state NEW,ESTABLISHED
      15 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:21715 state NEW,ESTABLISHED
      16 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:21714 state NEW,ESTABLISHED
      17 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 state NEW,ESTABLISHED
      18 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:80 state ESTABLISHED
      19 ACCEPT tcp -- 0.0.0.0/0 23.105.194.26 tcp dpt:8170 state NEW,ESTABLISHED
      20 ACCEPT udp -- 0.0.0.0/0 114.114.114.114 udp spts:1024:65535 dpt:53
      21 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 8
      22 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:8080 state ESTABLISHED
      23 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:8080 state ESTABLISHED
      24 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:123

      table:nat
      Chain PREROUTING (policy ACCEPT)
      num target prot opt source destination
      1 DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 to:172.17.42.1:80

      Chain POSTROUTING (policy ACCEPT)
      num target prot opt source destination
      1 MASQUERADE all -- 172.17.0.0/16 0.0.0.0/0
      2 MASQUERADE tcp -- 172.17.0.3 172.17.0.3 tcp dpt:80
      3 MASQUERADE tcp -- 172.17.0.3 172.17.0.3 tcp dpt:22
      4 MASQUERADE tcp -- 172.17.0.3 172.17.0.3 tcp dpt:21

      Chain OUTPUT (policy ACCEPT)
      num target prot opt source destination









      share|improve this question















      Recently, I used wget to try to pull down some packages through port 80. It is blocked by iptable (after the service iptables stops, wget can download the packages). Could anybody help me analyze my iptable rules?



      I think I've opened all the ports for local IPs (192.168.0.0/16, 10.0.0.0/8), so why is it blocked?



      My computer's IP is 192.168.1.168.



      If I prepare a web server at 192.168.1.170, I can download the page from 192.168.1.170.



      table:filter
      Chain INPUT (policy DROP)
      num target prot opt source destination
      1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
      2 ACCEPT all -- 0.0.0.0/8 0.0.0.0/0
      3 ACCEPT all -- 10.0.0.0/8 0.0.0.0/0
      4 ACCEPT all -- 127.0.0.0/8 0.0.0.0/0
      5 ACCEPT all -- 169.254.0.0/16 0.0.0.0/0
      6 ACCEPT all -- 172.16.0.0/12 0.0.0.0/0
      7 ACCEPT all -- 192.168.0.0/16 0.0.0.0/0
      8 ACCEPT all -- 224.0.0.0/4 0.0.0.0/0
      9 ACCEPT all -- 240.0.0.0/4 0.0.0.0/0
      10 ACCEPT all -- 144.168.60.32 0.0.0.0/0
      11 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:21701 state NEW,ESTABLISHED
      12 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:21701 state ESTABLISHED
      13 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:26941 state ESTABLISHED
      14 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:21713 state ESTABLISHED
      15 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:21715 state ESTABLISHED
      16 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:21714 state ESTABLISHED
      17 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:80 state ESTABLISHED
      18 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 state NEW,ESTABLISHED
      19 ACCEPT tcp -- 23.105.194.21 0.0.0.0/0 tcp spt:8170 state ESTABLISHED
      20 ACCEPT udp -- 114.114.114.114 0.0.0.0/0 udp spt:53 dpts:1024:65535
      21 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 8
      22 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 11
      23 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 0
      24 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:8080 state NEW,ESTABLISHED
      25 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp spt:123

      Chain FORWARD (policy DROP)
      num target prot opt source destination
      2 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
      3 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
      4 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0

      Chain OUTPUT (policy DROP)
      num target prot opt source destination
      1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
      2 ACCEPT all -- 0.0.0.0/0 0.0.0.0/8
      3 ACCEPT all -- 0.0.0.0/0 10.0.0.0/8
      4 ACCEPT all -- 0.0.0.0/0 127.0.0.0/8
      5 ACCEPT all -- 0.0.0.0/0 169.254.0.0/16
      6 ACCEPT all -- 0.0.0.0/0 172.16.0.0/12
      7 ACCEPT all -- 0.0.0.0/0 192.168.0.0/16
      8 ACCEPT all -- 0.0.0.0/0 208.0.0.0/4
      9 ACCEPT all -- 0.0.0.0/0 240.0.0.0/4
      10 ACCEPT all -- 0.0.0.0/0 144.168.60.32
      11 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:21701 state ESTABLISHED
      12 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:21701 state NEW,ESTABLISHED
      13 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:26941 state NEW,ESTABLISHED
      14 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:21713 state NEW,ESTABLISHED
      15 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:21715 state NEW,ESTABLISHED
      16 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:21714 state NEW,ESTABLISHED
      17 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 state NEW,ESTABLISHED
      18 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:80 state ESTABLISHED
      19 ACCEPT tcp -- 0.0.0.0/0 23.105.194.26 tcp dpt:8170 state NEW,ESTABLISHED
      20 ACCEPT udp -- 0.0.0.0/0 114.114.114.114 udp spts:1024:65535 dpt:53
      21 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 8
      22 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:8080 state ESTABLISHED
      23 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:8080 state ESTABLISHED
      24 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:123

      table:nat
      Chain PREROUTING (policy ACCEPT)
      num target prot opt source destination
      1 DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 to:172.17.42.1:80

      Chain POSTROUTING (policy ACCEPT)
      num target prot opt source destination
      1 MASQUERADE all -- 172.17.0.0/16 0.0.0.0/0
      2 MASQUERADE tcp -- 172.17.0.3 172.17.0.3 tcp dpt:80
      3 MASQUERADE tcp -- 172.17.0.3 172.17.0.3 tcp dpt:22
      4 MASQUERADE tcp -- 172.17.0.3 172.17.0.3 tcp dpt:21

      Chain OUTPUT (policy ACCEPT)
      num target prot opt source destination






      iptables






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Jan 30 at 6:51









      aliceinpalth

      800116




      800116










      asked Jan 30 at 5:24









      user2462304

      164




      164






















          2 Answers
          2






          active

          oldest

          votes

















          up vote
          1
          down vote













          The chain has to be ACCEPT, this is wrong:



          Chain INPUT (policy DROP)


          Then you want a last rule that blocks everything else:



          13740   717586 LOG        all  --  eth1   *       0.0.0.0/0            0.0.0.0/0            LOG flags 8 level 4 prefix "[iptables] A: "
          13740 717586 REJECT all -- eth1 * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable


          I personally like to LOG before the DROP or REJECT. The difference between the two is that REJECT sends a reply whereas the DROP just stops right there. I use DROP for certain things and REJECT for others...



          In most cases, the FORWARD is only necessary if you want a local computer on your LAN to access your Internet connection. Otherwise that one can remain DROP. I would not define any Output rules until the Input works.



          To look at your rules, I suggest the following:



          iptables -L -nvx | less -S


          which will give you the counts. That allows you to see where the packets get blocked. In your case, it would appear in the Chain INPUT such as:



          Chain INPUT (policy DROP 10 packets, 1240 bytes)





          share|improve this answer




























            up vote
            1
            down vote



            accepted










            I made a mistake. Somehow, I do not know why my device name changed from eth0 to eth1. So all the rules is only valid for eth0.



            @Alexis Wilke, thanks for your response!



            So anyone who ask question about iptables, should paste their "iptables -L -v" instead of "iptables -L".






            share|improve this answer























            • This is not really an answer. If Alexis' answer helped you find the solution, then this should possibly be a comment to his answer.
              – Kusalananda
              Jan 30 at 10:25










            • @Kusalananda The question is an induvidual debug problem, and this was the solution. I don't know what should be done in these cases - it is unlikely that anyone other googler would face the same problem, thus the question could be deleted. But also the big part of the site could be deleted on this reason; and it would be surreal for a Unix site to not allow induvidual system debug requests. I think the best to do if we allow it (as on the current site rules), but in this case it is an answer.
              – peterh
              Jan 30 at 10:40






            • 1




              @peterh I hear (see?) what you're saying, and I agree.
              – Kusalananda
              Jan 30 at 10:42










            • Ah! Yes. With time somehow the Ethernet numbers can change. It happened several times on my computer. I have eth0 to eth4 and they changed several times.
              – Alexis Wilke
              Jan 30 at 17:49











            Your Answer








            StackExchange.ready(function() {
            var channelOptions = {
            tags: "".split(" "),
            id: "106"
            };
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function() {
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled) {
            StackExchange.using("snippets", function() {
            createEditor();
            });
            }
            else {
            createEditor();
            }
            });

            function createEditor() {
            StackExchange.prepareEditor({
            heartbeatType: 'answer',
            convertImagesToLinks: false,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: null,
            bindNavPrevention: true,
            postfix: "",
            imageUploader: {
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            },
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            });


            }
            });














            draft saved

            draft discarded


















            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f420585%2fconfounding-problem-about-iptables%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            2 Answers
            2






            active

            oldest

            votes








            2 Answers
            2






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes








            up vote
            1
            down vote













            The chain has to be ACCEPT, this is wrong:



            Chain INPUT (policy DROP)


            Then you want a last rule that blocks everything else:



            13740   717586 LOG        all  --  eth1   *       0.0.0.0/0            0.0.0.0/0            LOG flags 8 level 4 prefix "[iptables] A: "
            13740 717586 REJECT all -- eth1 * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable


            I personally like to LOG before the DROP or REJECT. The difference between the two is that REJECT sends a reply whereas the DROP just stops right there. I use DROP for certain things and REJECT for others...



            In most cases, the FORWARD is only necessary if you want a local computer on your LAN to access your Internet connection. Otherwise that one can remain DROP. I would not define any Output rules until the Input works.



            To look at your rules, I suggest the following:



            iptables -L -nvx | less -S


            which will give you the counts. That allows you to see where the packets get blocked. In your case, it would appear in the Chain INPUT such as:



            Chain INPUT (policy DROP 10 packets, 1240 bytes)





            share|improve this answer

























              up vote
              1
              down vote













              The chain has to be ACCEPT, this is wrong:



              Chain INPUT (policy DROP)


              Then you want a last rule that blocks everything else:



              13740   717586 LOG        all  --  eth1   *       0.0.0.0/0            0.0.0.0/0            LOG flags 8 level 4 prefix "[iptables] A: "
              13740 717586 REJECT all -- eth1 * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable


              I personally like to LOG before the DROP or REJECT. The difference between the two is that REJECT sends a reply whereas the DROP just stops right there. I use DROP for certain things and REJECT for others...



              In most cases, the FORWARD is only necessary if you want a local computer on your LAN to access your Internet connection. Otherwise that one can remain DROP. I would not define any Output rules until the Input works.



              To look at your rules, I suggest the following:



              iptables -L -nvx | less -S


              which will give you the counts. That allows you to see where the packets get blocked. In your case, it would appear in the Chain INPUT such as:



              Chain INPUT (policy DROP 10 packets, 1240 bytes)





              share|improve this answer























                up vote
                1
                down vote










                up vote
                1
                down vote









                The chain has to be ACCEPT, this is wrong:



                Chain INPUT (policy DROP)


                Then you want a last rule that blocks everything else:



                13740   717586 LOG        all  --  eth1   *       0.0.0.0/0            0.0.0.0/0            LOG flags 8 level 4 prefix "[iptables] A: "
                13740 717586 REJECT all -- eth1 * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable


                I personally like to LOG before the DROP or REJECT. The difference between the two is that REJECT sends a reply whereas the DROP just stops right there. I use DROP for certain things and REJECT for others...



                In most cases, the FORWARD is only necessary if you want a local computer on your LAN to access your Internet connection. Otherwise that one can remain DROP. I would not define any Output rules until the Input works.



                To look at your rules, I suggest the following:



                iptables -L -nvx | less -S


                which will give you the counts. That allows you to see where the packets get blocked. In your case, it would appear in the Chain INPUT such as:



                Chain INPUT (policy DROP 10 packets, 1240 bytes)





                share|improve this answer












                The chain has to be ACCEPT, this is wrong:



                Chain INPUT (policy DROP)


                Then you want a last rule that blocks everything else:



                13740   717586 LOG        all  --  eth1   *       0.0.0.0/0            0.0.0.0/0            LOG flags 8 level 4 prefix "[iptables] A: "
                13740 717586 REJECT all -- eth1 * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable


                I personally like to LOG before the DROP or REJECT. The difference between the two is that REJECT sends a reply whereas the DROP just stops right there. I use DROP for certain things and REJECT for others...



                In most cases, the FORWARD is only necessary if you want a local computer on your LAN to access your Internet connection. Otherwise that one can remain DROP. I would not define any Output rules until the Input works.



                To look at your rules, I suggest the following:



                iptables -L -nvx | less -S


                which will give you the counts. That allows you to see where the packets get blocked. In your case, it would appear in the Chain INPUT such as:



                Chain INPUT (policy DROP 10 packets, 1240 bytes)






                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Jan 30 at 8:07









                Alexis Wilke

                939615




                939615
























                    up vote
                    1
                    down vote



                    accepted










                    I made a mistake. Somehow, I do not know why my device name changed from eth0 to eth1. So all the rules is only valid for eth0.



                    @Alexis Wilke, thanks for your response!



                    So anyone who ask question about iptables, should paste their "iptables -L -v" instead of "iptables -L".






                    share|improve this answer























                    • This is not really an answer. If Alexis' answer helped you find the solution, then this should possibly be a comment to his answer.
                      – Kusalananda
                      Jan 30 at 10:25










                    • @Kusalananda The question is an induvidual debug problem, and this was the solution. I don't know what should be done in these cases - it is unlikely that anyone other googler would face the same problem, thus the question could be deleted. But also the big part of the site could be deleted on this reason; and it would be surreal for a Unix site to not allow induvidual system debug requests. I think the best to do if we allow it (as on the current site rules), but in this case it is an answer.
                      – peterh
                      Jan 30 at 10:40






                    • 1




                      @peterh I hear (see?) what you're saying, and I agree.
                      – Kusalananda
                      Jan 30 at 10:42










                    • Ah! Yes. With time somehow the Ethernet numbers can change. It happened several times on my computer. I have eth0 to eth4 and they changed several times.
                      – Alexis Wilke
                      Jan 30 at 17:49















                    up vote
                    1
                    down vote



                    accepted










                    I made a mistake. Somehow, I do not know why my device name changed from eth0 to eth1. So all the rules is only valid for eth0.



                    @Alexis Wilke, thanks for your response!



                    So anyone who ask question about iptables, should paste their "iptables -L -v" instead of "iptables -L".






                    share|improve this answer























                    • This is not really an answer. If Alexis' answer helped you find the solution, then this should possibly be a comment to his answer.
                      – Kusalananda
                      Jan 30 at 10:25










                    • @Kusalananda The question is an induvidual debug problem, and this was the solution. I don't know what should be done in these cases - it is unlikely that anyone other googler would face the same problem, thus the question could be deleted. But also the big part of the site could be deleted on this reason; and it would be surreal for a Unix site to not allow induvidual system debug requests. I think the best to do if we allow it (as on the current site rules), but in this case it is an answer.
                      – peterh
                      Jan 30 at 10:40






                    • 1




                      @peterh I hear (see?) what you're saying, and I agree.
                      – Kusalananda
                      Jan 30 at 10:42










                    • Ah! Yes. With time somehow the Ethernet numbers can change. It happened several times on my computer. I have eth0 to eth4 and they changed several times.
                      – Alexis Wilke
                      Jan 30 at 17:49













                    up vote
                    1
                    down vote



                    accepted







                    up vote
                    1
                    down vote



                    accepted






                    I made a mistake. Somehow, I do not know why my device name changed from eth0 to eth1. So all the rules is only valid for eth0.



                    @Alexis Wilke, thanks for your response!



                    So anyone who ask question about iptables, should paste their "iptables -L -v" instead of "iptables -L".






                    share|improve this answer














                    I made a mistake. Somehow, I do not know why my device name changed from eth0 to eth1. So all the rules is only valid for eth0.



                    @Alexis Wilke, thanks for your response!



                    So anyone who ask question about iptables, should paste their "iptables -L -v" instead of "iptables -L".







                    share|improve this answer














                    share|improve this answer



                    share|improve this answer








                    edited yesterday









                    Rui F Ribeiro

                    38.6k1479128




                    38.6k1479128










                    answered Jan 30 at 8:46









                    user2462304

                    164




                    164












                    • This is not really an answer. If Alexis' answer helped you find the solution, then this should possibly be a comment to his answer.
                      – Kusalananda
                      Jan 30 at 10:25










                    • @Kusalananda The question is an induvidual debug problem, and this was the solution. I don't know what should be done in these cases - it is unlikely that anyone other googler would face the same problem, thus the question could be deleted. But also the big part of the site could be deleted on this reason; and it would be surreal for a Unix site to not allow induvidual system debug requests. I think the best to do if we allow it (as on the current site rules), but in this case it is an answer.
                      – peterh
                      Jan 30 at 10:40






                    • 1




                      @peterh I hear (see?) what you're saying, and I agree.
                      – Kusalananda
                      Jan 30 at 10:42










                    • Ah! Yes. With time somehow the Ethernet numbers can change. It happened several times on my computer. I have eth0 to eth4 and they changed several times.
                      – Alexis Wilke
                      Jan 30 at 17:49


















                    • This is not really an answer. If Alexis' answer helped you find the solution, then this should possibly be a comment to his answer.
                      – Kusalananda
                      Jan 30 at 10:25










                    • @Kusalananda The question is an induvidual debug problem, and this was the solution. I don't know what should be done in these cases - it is unlikely that anyone other googler would face the same problem, thus the question could be deleted. But also the big part of the site could be deleted on this reason; and it would be surreal for a Unix site to not allow induvidual system debug requests. I think the best to do if we allow it (as on the current site rules), but in this case it is an answer.
                      – peterh
                      Jan 30 at 10:40






                    • 1




                      @peterh I hear (see?) what you're saying, and I agree.
                      – Kusalananda
                      Jan 30 at 10:42










                    • Ah! Yes. With time somehow the Ethernet numbers can change. It happened several times on my computer. I have eth0 to eth4 and they changed several times.
                      – Alexis Wilke
                      Jan 30 at 17:49
















                    This is not really an answer. If Alexis' answer helped you find the solution, then this should possibly be a comment to his answer.
                    – Kusalananda
                    Jan 30 at 10:25




                    This is not really an answer. If Alexis' answer helped you find the solution, then this should possibly be a comment to his answer.
                    – Kusalananda
                    Jan 30 at 10:25












                    @Kusalananda The question is an induvidual debug problem, and this was the solution. I don't know what should be done in these cases - it is unlikely that anyone other googler would face the same problem, thus the question could be deleted. But also the big part of the site could be deleted on this reason; and it would be surreal for a Unix site to not allow induvidual system debug requests. I think the best to do if we allow it (as on the current site rules), but in this case it is an answer.
                    – peterh
                    Jan 30 at 10:40




                    @Kusalananda The question is an induvidual debug problem, and this was the solution. I don't know what should be done in these cases - it is unlikely that anyone other googler would face the same problem, thus the question could be deleted. But also the big part of the site could be deleted on this reason; and it would be surreal for a Unix site to not allow induvidual system debug requests. I think the best to do if we allow it (as on the current site rules), but in this case it is an answer.
                    – peterh
                    Jan 30 at 10:40




                    1




                    1




                    @peterh I hear (see?) what you're saying, and I agree.
                    – Kusalananda
                    Jan 30 at 10:42




                    @peterh I hear (see?) what you're saying, and I agree.
                    – Kusalananda
                    Jan 30 at 10:42












                    Ah! Yes. With time somehow the Ethernet numbers can change. It happened several times on my computer. I have eth0 to eth4 and they changed several times.
                    – Alexis Wilke
                    Jan 30 at 17:49




                    Ah! Yes. With time somehow the Ethernet numbers can change. It happened several times on my computer. I have eth0 to eth4 and they changed several times.
                    – Alexis Wilke
                    Jan 30 at 17:49


















                    draft saved

                    draft discarded




















































                    Thanks for contributing an answer to Unix & Linux Stack Exchange!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid



                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.


                    To learn more, see our tips on writing great answers.





                    Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


                    Please pay close attention to the following guidance:


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid



                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.


                    To learn more, see our tips on writing great answers.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f420585%2fconfounding-problem-about-iptables%23new-answer', 'question_page');
                    }
                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    Popular posts from this blog

                    Accessing regular linux commands in Huawei's Dopra Linux

                    Can't connect RFCOMM socket: Host is down

                    Kernel panic - not syncing: Fatal Exception in Interrupt