# iptables rule not catching packets

## javeree

I have the following FORWARD chain:

```
Chain FORWARD (policy ACCEPT 199K packets, 12M bytes)

num   pkts bytes target     prot opt in     out     source               destination

1      235 12196 TCPMSS     tcp  --  ppp1   any     anywhere             anywhere             tcp flags:SYN,RST/SYN TCPMSS clamp to PMTU

2      236 12268 TCPMSS     tcp  --  any    ppp1    anywhere             anywhere             tcp flags:SYN,RST/SYN TCPMSS clamp to PMTU

3     457K  389M TCP_FLAGS  tcp  --  any    any     anywhere             anywhere

4     196K   12M            tcp  --  any    ppp1    anywhere             anywhere             tcp dpt:https state NEW,ESTABLISHED

5     2973  186K            tcp  --  any    ppp1    anywhere             anywhere             tcp dpt:http state NEW,ESTABLISHED

6     258K  377M ACCEPT     all  --  ppp1   any     anywhere             anywhere             ctstate RELATED,ESTABLISHED

7        0     0 ACCEPT     all  --  ethm   br0     192.168.1.0/24       192.168.4.0/24

8        0     0 ACCEPT     all  --  br0    ethm    192.168.4.0/24       192.168.1.0/24

9     199K   12M LOG        all  --  any    any     anywhere             anywhere             LOG level warning

```

Yet, I see the following in my LOG:

```
[60922.394925] IN=br0 OUT=ppp1 MAC=00:00:00:00:6b:52:40:61:86:36:e8:6b:08:00 SRC=192.168.4.61 DST=191.232.139.254 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=27192 DF PROTO=TCP SPT=55392 DPT=443 WINDOW=8192 RES=0x00 SYN URGP=0

[60922.444144] IN=br0 OUT=ppp1 MAC=00:00:00:00:6b:52:40:61:86:36:e8:6b:08:00 SRC=192.168.4.61 DST=191.232.139.254 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=27193 DF PROTO=TCP SPT=55392 DPT=443 WINDOW=16560 RES=0x00 ACK URGP=0

[60922.444356] IN=br0 OUT=ppp1 MAC=00:00:00:00:6b:52:40:61:86:36:e8:6b:08:00 SRC=192.168.4.61 DST=191.232.139.254 LEN=175 TOS=0x00 PREC=0x00 TTL=127 ID=27194 DF PROTO=TCP SPT=55392 DPT=443 WINDOW=16560 RES=0x00 ACK PSH URGP=0

[60922.498386] IN=br0 OUT=ppp1 MAC=00:00:00:00:6b:52:40:61:86:36:e8:6b:08:00 SRC=192.168.4.61 DST=191.232.139.254 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=27195 DF PROTO=TCP SPT=55392 DPT=443 WINDOW=16560 RES=0x00 ACK URGP=0

[60922.517634] IN=br0 OUT=ppp1 MAC=00:00:00:00:6b:52:40:61:86:36:e8:6b:08:00 SRC=192.168.4.61 DST=191.232.139.254 LEN=206 TOS=0x00 PREC=0x00 TTL=127 ID=27196 DF PROTO=TCP SPT=55392 DPT=443 WINDOW=16560 RES=0x00 ACK PSH URGP=0

[60922.572271] IN=br0 OUT=ppp1 MAC=00:00:00:00:6b:52:40:61:86:36:e8:6b:08:00 SRC=192.168.4.61 DST=191.232.139.254 LEN=450 TOS=0x00 PREC=0x00 TTL=127 ID=27197 DF PROTO=TCP SPT=55392 DPT=443 WINDOW=16545 RES=0x00 ACK PSH URGP=0

[60922.572499] IN=br0 OUT=ppp1 MAC=00:00:00:00:6b:52:40:61:86:36:e8:6b:08:00 SRC=192.168.4.61 DST=191.232.139.254 LEN=546 TOS=0x00 PREC=0x00 TTL=127 ID=27198 DF PROTO=TCP SPT=55392 DPT=443 WINDOW=16545 RES=0x00 ACK PSH URGP=0

[60922.917406] IN=br0 OUT=ppp1 MAC=00:00:00:00:6b:52:40:61:86:36:e8:6b:08:00 SRC=192.168.4.61 DST=191.232.139.254 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=27199 DF PROTO=TCP SPT=55392 DPT=443 WINDOW=16446 RES=0x00 ACK URGP=0

[60957.176428] IN=br0 OUT=ppp1 MAC=00:00:00:00:6b:52:40:61:86:36:e8:6b:08:00 SRC=192.168.4.61 DST=23.218.162.118 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=27225 DF PROTO=TCP SPT=55393 DPT=80 WINDOW=8192 RES=0x00 SYN URGP=0

[60957.197407] IN=br0 OUT=ppp1 MAC=00:00:00:00:6b:52:40:61:86:36:e8:6b:08:00 SRC=192.168.4.61 DST=23.218.162.118 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=27226 DF PROTO=TCP SPT=55393 DPT=80 WINDOW=16698 RES=0x00 ACK URGP=0

[60957.197536] IN=br0 OUT=ppp1 MAC=00:00:00:00:6b:52:40:61:86:36:e8:6b:08:00 SRC=192.168.4.61 DST=23.218.162.118 LEN=330 TOS=0x00 PREC=0x00 TTL=127 ID=27227 DF PROTO=TCP SPT=55393 DPT=80 WINDOW=16698 RES=0x00 ACK PSH URGP=0

[60957.423076] IN=br0 OUT=ppp1 MAC=00:00:00:00:6b:52:40:61:86:36:e8:6b:08:00 SRC=192.168.4.61 DST=23.218.162.118 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=27228 DF PROTO=TCP SPT=55393 DPT=80 WINDOW=16635 RES=0x00 ACK URGP=0

[60957.444131] IN=br0 OUT=ppp1 MAC=00:00:00:00:6b:52:40:61:86:36:e8:6b:08:00 SRC=192.168.4.61 DST=23.218.162.118 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=27229 DF PROTO=TCP SPT=55393 DPT=80 WINDOW=16635 RES=0x00 ACK URGP=0

[60982.719511] IN=br0 OUT=ppp1 MAC=00:00:00:00:6b:52:40:61:86:36:e8:6b:08:00 SRC=192.168.4.61 DST=191.232.139.254 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=27274 DF PROTO=TCP SPT=55392 DPT=443 WINDOW=0 RES=0x00 ACK RST URGP=0

[61108.138361] IN=br0 OUT=ppp1 MAC=00:00:00:00:6b:52:40:61:86:36:e8:6b:08:00 SRC=192.168.4.61 DST=23.218.162.118 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=27416 DF PROTO=TCP SPT=55393 DPT=80 WINDOW=0 RES=0x00 ACK RST URGP=0

```

Why would these packets to ports 80 and 443 not be intercepted by rules 4 and 5 ? For the ACK or ACK RST packets, I could assume these are packets that have been delayed so Long that the conntrack table does not recognize them, but the SYN packet should definitely result in state NEW.

FYI, the source PC is running Windows, and my son plays various online games, that may act as Servers (normally upnp takes care of that)

----------

## papahuhn

```

    -j, --jump target

              [...]

              If this option is omitted  in

              a rule (and -g is not used), then matching the rule will have no

              effect on the packet's fate, but the counters on the  rule  will

              be incremented.

```

----------

## javeree

stupid me, overlooked there was no target.

Thanks

----------

