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

Initially I thought iptables was blocking all http traffic for a reverse proxy I have set up with pound. This was working prior to a system update (ClearOS 6.2.x).

Now after implementing logging for iptables as noted in the remark below:

# Replace IP in the following with the one you're looking for:
iptables -t raw -A PREROUTING -p tcp --destination 192.168.0.0/24 --dport 80 -j TRACE
iptables -t raw -A OUTPUT -p tcp --destination 192.168.0.0/24 --dport 80 -j TRACE

As far as rule numbers go, here are the rules that are set up presently:

$ iptables -L -n -v --line-numbers
Chain INPUT (policy DROP 68523 packets, 6058K bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1     4477  353K DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           state INVALID 
2        0     0 REJECT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:0x12/0x12 state NEW reject-with tcp-reset 
3      589 86548 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:!0x17/0x02 state NEW 
4        0     0 DROP       all  --  eth1   *       127.0.0.0/8          0.0.0.0/0           
5        0     0 DROP       all  --  eth1   *       169.254.0.0/16       0.0.0.0/0           
6      607 59097 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
7        0     0 ACCEPT     all  --  pptp+  *       0.0.0.0/0            0.0.0.0/0           
8        0     0 ACCEPT     all  --  tun+   *       0.0.0.0/0            0.0.0.0/0           
9    30938 3055K ACCEPT     all  --  eth0   *       0.0.0.0/0            0.0.0.0/0           
10       0     0 ACCEPT     icmp --  eth1   *       0.0.0.0/0            0.0.0.0/0           icmp type 0 
11       0     0 ACCEPT     icmp --  eth1   *       0.0.0.0/0            0.0.0.0/0           icmp type 3 
12     191 12161 ACCEPT     icmp --  eth1   *       0.0.0.0/0            0.0.0.0/0           icmp type 8 
13       0     0 ACCEPT     icmp --  eth1   *       0.0.0.0/0            0.0.0.0/0           icmp type 11 
14       0     0 ACCEPT     udp  --  eth1   *       0.0.0.0/0            0.0.0.0/0           udp spt:67 dpt:68 
15       0     0 ACCEPT     tcp  --  eth1   *       0.0.0.0/0            0.0.0.0/0           tcp spt:67 dpt:68 
16       2   120 ACCEPT     tcp  --  *      *       0.0.0.0/0            xx.xxx.xx.xxx       tcp dpt:80 
17       0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            xx.xxx.xx.xxx       tcp dpt:443 
18       0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            xx.xxx.xx.xxx       tcp dpt:1875 
19   17621 2309K ACCEPT     udp  --  eth1   *       0.0.0.0/0            0.0.0.0/0           udp dpts:1024:65535 state RELATED,ESTABLISHED 
20     503 20817 ACCEPT     tcp  --  eth1   *       0.0.0.0/0            0.0.0.0/0           tcp dpts:1024:65535 state RELATED,ESTABLISHED 
21   68523 6058K LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 4 

Chain FORWARD (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1    27193 7080K ACCEPT     tcp  --  *      eth0    0.0.0.0/0            192.168.0.50        tcp dpt:20189 
2        0     0 ACCEPT     tcp  --  *      eth0    0.0.0.0/0            192.168.0.5         tcp dpt:52498 
3        0     0 ACCEPT     tcp  --  *      eth0    0.0.0.0/0            192.168.0.50        tcp dpt:32022 
4     5425  257K ACCEPT     tcp  --  *      eth0    0.0.0.0/0            192.168.0.50        tcp dpt:42312 
5        0     0 ACCEPT     tcp  --  *      eth0    0.0.0.0/0            192.168.0.5         tcp dpt:24583 
6      11M   15G ACCEPT     tcp  --  *      eth0    0.0.0.0/0            192.168.0.5         tcp dpt:28657 
7        0     0 ACCEPT     tcp  --  *      eth0    0.0.0.0/0            192.168.0.5         tcp dpt:5000 
8      16M 8263M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
9     292K   23M ACCEPT     all  --  eth0   *       0.0.0.0/0            0.0.0.0/0           
10       0     0 ACCEPT     all  --  pptp+  *       0.0.0.0/0            0.0.0.0/0           
11       0     0 ACCEPT     all  --  tun+   *       0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1      639 63549 ACCEPT     all  --  *      lo      0.0.0.0/0            0.0.0.0/0           
2        0     0 ACCEPT     all  --  *      pptp+   0.0.0.0/0            0.0.0.0/0           
3        0     0 ACCEPT     all  --  *      tun+    0.0.0.0/0            0.0.0.0/0           
4    26286 3837K ACCEPT     all  --  *      eth0    0.0.0.0/0            0.0.0.0/0           
5      649 85077 ACCEPT     icmp --  *      eth1    0.0.0.0/0            0.0.0.0/0           
6        0     0 ACCEPT     udp  --  *      eth1    0.0.0.0/0            0.0.0.0/0           udp spt:68 dpt:67 
7        0     0 ACCEPT     tcp  --  *      eth1    0.0.0.0/0            0.0.0.0/0           tcp spt:68 dpt:67 
8        2    80 ACCEPT     tcp  --  *      eth1    xx.xxx.xx.xxx        0.0.0.0/0           tcp spt:80 
9        0     0 ACCEPT     tcp  --  *      eth1    xx.xxx.xx.xxx        0.0.0.0/0           tcp spt:443 
10       0     0 ACCEPT     tcp  --  *      eth1    xx.xxx.xx.xxx        0.0.0.0/0           tcp spt:1875 
11   18370 1245K ACCEPT     all  --  *      eth1    0.0.0.0/0            0.0.0.0/0           

Chain drop-lan (0 references)
num   pkts bytes target     prot opt in     out     source               destination         
1        0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           

I'm seeing traffic such as the following:

May  4 21:46:57 gateway kernel: TRACE: raw:PREROUTING:policy:2 IN=eth0 OUT= MAC=00:1e:71:3d:34:77:01:24:cf:da:1d:e3:02:01 SRC=192.168.0.5 DST=public_ip LEN=64 TOS=0x00 PREC=0x00 TTL=64 ID=50119 DF PROTO=TCP SPT=56744 DPT=80 SEQ=2879375707 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B4010303030101080A24B2D51D0000000004020000) 
May  4 21:46:57 gateway kernel: TRACE: mangle:PREROUTING:policy:1 IN=eth0 OUT= MAC=00:1e:71:3d:34:77:01:24:cf:da:1d:e3:02:01 SRC=192.168.0.5 DST=public_ip LEN=64 TOS=0x00 PREC=0x00 TTL=64 ID=50119 DF PROTO=TCP SPT=56744 DPT=80 SEQ=2879375707 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B4010303030101080A24B2D51D0000000004020000) 
May  4 21:46:57 gateway kernel: TRACE: nat:PREROUTING:policy:8 IN=eth0 OUT= MAC=00:1e:71:3d:34:77:01:24:cf:da:1d:e3:02:01 SRC=192.168.0.5 DST=public_ip LEN=64 TOS=0x00 PREC=0x00 TTL=64 ID=50119 DF PROTO=TCP SPT=56744 DPT=80 SEQ=2879375707 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B4010303030101080A24B2D51D0000000004020000) 
May  4 21:46:57 gateway kernel: TRACE: mangle:INPUT:policy:1 IN=eth0 OUT= MAC=00:1e:71:3d:34:77:01:24:cf:da:1d:e3:02:01 SRC=192.168.0.5 DST=public_ip LEN=64 TOS=0x00 PREC=0x00 TTL=64 ID=50119 DF PROTO=TCP SPT=56744 DPT=80 SEQ=2879375707 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B4010303030101080A24B2D51D0000000004020000) 
May  4 21:46:57 gateway kernel: TRACE: filter:INPUT:rule:9 IN=eth0 OUT= MAC=00:1e:71:3d:34:77:01:24:cf:da:1d:e3:02:01 SRC=192.168.0.5 DST=public_ip LEN=64 TOS=0x00 PREC=0x00 TTL=64 ID=50119 DF PROTO=TCP SPT=56744 DPT=80 SEQ=2879375707 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B4010303030101080A24B2D51D0000000004020000) 
May  4 21:46:57 gateway kernel: TRACE: raw:PREROUTING:policy:2 IN=eth0 OUT= MAC=00:1e:71:3d:34:77:01:24:cf:da:1d:e3:02:01 SRC=192.168.0.5 DST=public_ip LEN=64 TOS=0x00 PREC=0x00 TTL=64 ID=52722 DF PROTO=TCP SPT=56745 DPT=80 SEQ=1024677181 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B4010303030101080A24B2D51D0000000004020000) 
May  4 21:46:57 gateway kernel: TRACE: mangle:PREROUTING:policy:1 IN=eth0 OUT= MAC=00:1e:71:3d:34:77:01:24:cf:da:1d:e3:02:01 SRC=192.168.0.5 DST=public_ip LEN=64 TOS=0x00 PREC=0x00 TTL=64 ID=52722 DF PROTO=TCP SPT=56745 DPT=80 SEQ=1024677181 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B4010303030101080A24B2D51D0000000004020000) 
May  4 21:46:57 gateway kernel: TRACE: nat:PREROUTING:policy:8 IN=eth0 OUT= MAC=00:1e:71:3d:34:77:01:24:cf:da:1d:e3:02:01 SRC=192.168.0.5 DST=public_ip LEN=64 TOS=0x00 PREC=0x00 TTL=64 ID=52722 DF PROTO=TCP SPT=56745 DPT=80 SEQ=1024677181 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B4010303030101080A24B2D51D0000000004020000) 
May  4 21:46:57 gateway kernel: TRACE: mangle:INPUT:policy:1 IN=eth0 OUT= MAC=00:1e:71:3d:34:77:01:24:cf:da:1d:e3:02:01 SRC=192.168.0.5 DST=public_ip LEN=64 TOS=0x00 PREC=0x00 TTL=64 ID=52722 DF PROTO=TCP SPT=56745 DPT=80 SEQ=1024677181 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B4010303030101080A24B2D51D0000000004020000) 
May  4 21:46:57 gateway kernel: TRACE: filter:INPUT:rule:9 IN=eth0 OUT= MAC=00:1e:71:3d:34:77:01:24:cf:da:1d:e3:02:01 SRC=192.168.0.5 DST=public_ip LEN=64 TOS=0x00 PREC=0x00 TTL=64 ID=52722 DF PROTO=TCP SPT=56745 DPT=80 SEQ=1024677181 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B4010303030101080A24B2D51D0000000004020000) 

How do I interpret this and modify the rules to allow this traffic to pass on in?

share|improve this question
1  
Wireshark will see incoming on a given before the filtering rules are applied. So seeing the traffic, doesn't mean that iptables is permitting it. You may want to use the trace for the source IP like I described in this question. serverfault.com/questions/122157/debugger-for-iptables/… –  Zoredache May 5 '12 at 1:38
    
@Zoredache did you note my iptables log line in the above? I'm simply saying with that that I do not see any DENY's or ACCEPT's that pertain to this traffic and therefore I am left thinking that iptables isn't an issue. Is there a more verbose way of logging with iptables than the above? –  ylluminate May 5 '12 at 1:40
1  
Yes, see the linked question, where I describe how to use the TRACE feature. –  Zoredache May 5 '12 at 1:42
    
I see. So effectively, in this case, I'd use the public interface ip for the destination ip whilst seeking to trace out input from the outside in, correct? –  ylluminate May 5 '12 at 1:44
    
@Zoredache thanks for that, I've added more details to the original post now given that. Hmmmmm. –  ylluminate May 5 '12 at 1:53
show 2 more comments

Your Answer

 
discard

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

Browse other questions tagged or ask your own question.