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
iptables
edited Jan 30 at 6:51
aliceinpalth
800116
asked Jan 30 at 5:24
user2462304
164
add a comment |
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
iptables
edited Jan 30 at 6:51
aliceinpalth
800116
asked Jan 30 at 5:24
user2462304
164
add a comment |
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
iptables
edited Jan 30 at 6:51
aliceinpalth
800116
asked Jan 30 at 5:24
user2462304
164
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
iptables
edited Jan 30 at 6:51
aliceinpalth
800116
asked Jan 30 at 5:24
user2462304
164
edited Jan 30 at 6:51
aliceinpalth
800116
asked Jan 30 at 5:24
user2462304
164
edited Jan 30 at 6:51
aliceinpalth
800116
edited Jan 30 at 6:51
aliceinpalth
800116
edited Jan 30 at 6:51
aliceinpalth
800116
800116
asked Jan 30 at 5:24
user2462304
164
asked Jan 30 at 5:24
user2462304
164
asked Jan 30 at 5:24
user2462304
164
164
add a comment |
add a comment |
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)
answered Jan 30 at 8:07
Alexis Wilke
939615
add a comment |
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".
edited yesterday
Rui F Ribeiro
38.6k1479128
answered Jan 30 at 8:46
user2462304
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
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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)
answered Jan 30 at 8:07
Alexis Wilke
939615
add a comment |
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)
answered Jan 30 at 8:07
Alexis Wilke
939615
add a comment |
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)
answered Jan 30 at 8:07
Alexis Wilke
939615
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)
answered Jan 30 at 8:07
Alexis Wilke
939615
answered Jan 30 at 8:07
Alexis Wilke
939615
answered Jan 30 at 8:07
Alexis Wilke
939615
answered Jan 30 at 8:07
Alexis Wilke
939615
939615
add a comment |
add a comment |
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".
edited yesterday
Rui F Ribeiro
38.6k1479128
answered Jan 30 at 8:46
user2462304
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
add a comment |
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".
edited yesterday
Rui F Ribeiro
38.6k1479128
answered Jan 30 at 8:46
user2462304
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
add a comment |
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".
edited yesterday
Rui F Ribeiro
38.6k1479128
answered Jan 30 at 8:46
user2462304
164
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".
edited yesterday
Rui F Ribeiro
38.6k1479128
answered Jan 30 at 8:46
user2462304
164
edited yesterday
Rui F Ribeiro
38.6k1479128
edited yesterday
Rui F Ribeiro
38.6k1479128
edited yesterday
Rui F Ribeiro
38.6k1479128
38.6k1479128
answered Jan 30 at 8:46
user2462304
164
answered Jan 30 at 8:46
user2462304
164
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
add a comment |
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
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
