strange log on gateway inside []

strange log on gateway inside []

[Michele Petrazzo - Unipex]

Hi list,
I have a firewall that log some strange, for me, packets on the OUTPUT 
chain that I haven't see before. This is a typical log:

Firewall DROPOUT- IN= OUT=eth0 SRC=MYPUBBIP DST=188.153.11.87
     LEN=92 TOS=0x00 PREC=0xC0 TTL=64 ID=49303 PROTO=ICMP TYPE=3 CODE=3
[SRC=188.153.11.87 DST=MYADDITIONALIP LEN=64 TOS=0x00 PREC=0x00 TTL=118 
ID=28851 DF PROTO=TCP SPT=12387 DPT=51684 WINDOW=17424 RES=0x00 ACK SYN 
URGP=0 ]

My output chain:
*filter
:OUTPUT DROP [4831251:620928037]
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -j LOG --log-prefix "Firewall DROPOUT- "

On it I have more that one pubb ip addrs and, the MYPUBBIP is the first 
and primary, the MYADDITIONALIP if one of the secondaries.

The question. Why I see this log and why my fw want to talk with 
external and, the last, why the kernel double log talk and one is inside 
the brackets  [ ] ?

Thanks,
Michele

Re: strange log on gateway inside []

[Jan Engelhardt]

On Thursday 2010-07-29 10:38, Michele Petrazzo - Unipex wrote:

> Hi list,
> I have a firewall that log some strange, for me, packets on the OUTPUT chain
> that I haven't see before. This is a typical log:
>
> Firewall DROPOUT- IN= OUT=eth0 SRC=MYPUBBIP DST=188.153.11.87
>    LEN=92 TOS=0x00 PREC=0xC0 TTL=64 ID=49303 PROTO=ICMP TYPE=3 CODE=3
> [SRC=188.153.11.87 DST=MYADDITIONALIP LEN=64 TOS=0x00 PREC=0x00 TTL=118
> ID=28851 DF PROTO=TCP SPT=12387 DPT=51684 WINDOW=17424 RES=0x00 ACK SYN URGP=0
> ]
>
> My output chain:
> *filter
> :OUTPUT DROP [4831251:620928037]
> -A OUTPUT -o lo -j ACCEPT
> -A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
> -A OUTPUT -j LOG --log-prefix "Firewall DROPOUT- "

So what's left is INVALID packets.

> The question. Why I see this log and why my fw want to talk with external and,
> the last, why the kernel double log talk and one is inside the brackets  [ ] ?

Because those are the contents of the ICMP packet. See the RFC.

Re: strange log on gateway inside []

[Michele Petrazzo - Unipex]

Jan Engelhardt ha scritto:
>> My output chain:
>> *filter
>> :OUTPUT DROP [4831251:620928037]
>> -A OUTPUT -o lo -j ACCEPT
>> -A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
>> -A OUTPUT -j LOG --log-prefix "Firewall DROPOUT- "
>
> So what's left is INVALID packets.
>

First, thanks.
Seem that a rule that drop the INVALID packets to the trick. But... drop 
or reject the invalid packets?

>> The question. Why I see this log and why my fw want to talk with external and,
>> the last, why the kernel double log talk and one is inside the brackets  [ ] ?
>
> Because those are the contents of the ICMP packet. See the RFC.

Append also with tcp, no only icmp.
P.s. Have you a rfc number?

And the last, have you also an rfc that explain why and where invalid 
come from?

Thanks

Re: strange log on gateway inside []

[Pascal Hambourg]

Hello,

Michele Petrazzo - Unipex a écrit :
> Hi list,
> I have a firewall that log some strange, for me, packets on the OUTPUT
> chain that I haven't see before. This is a typical log:
> 
> Firewall DROPOUT- IN= OUT=eth0 SRC=MYPUBBIP DST=188.153.11.87
>     LEN=92 TOS=0x00 PREC=0xC0 TTL=64 ID=49303 PROTO=ICMP TYPE=3 CODE=3
> [SRC=188.153.11.87 DST=MYADDITIONALIP LEN=64 TOS=0x00 PREC=0x00 TTL=118
> ID=28851 DF PROTO=TCP SPT=12387 DPT=51684 WINDOW=17424 RES=0x00 ACK SYN
> URGP=0 ]
> 
> My output chain:
> *filter
> :OUTPUT DROP [4831251:620928037]
> -A OUTPUT -o lo -j ACCEPT
> -A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
> -A OUTPUT -j LOG --log-prefix "Firewall DROPOUT- "
> 
> On it I have more that one pubb ip addrs and, the MYPUBBIP is the first
> and primary, the MYADDITIONALIP if one of the secondaries.
> 
> The question. Why I see this log and why my fw want to talk with
> external and, the last, why the kernel double log talk and one is inside
> the brackets  [ ] ?

This is an ICMP error packet. Type 3 code 3 means "destination port
unreachable". An ICMP error packet contains the beginning (including the
header) of the original packet which triggered the error, printed within
brackets in the log. Here the original packet was TCP from 188.153.11.87
to MYADDITIONALIP. ICMP port unreachable is not the natural reply to an
unexpected TCP packet, so I guess it was generated by a REJECT target in
the INPUT or FORWARD chain. If the original packet was in the INVALID
state (or UNTRACKED if you used the NOTRACK target), then the ICMP error
packet is in the INVALID state instead of RELATED.

Re: strange log on gateway inside []

[Jan Engelhardt]

On Thursday 2010-07-29 11:18, Michele Petrazzo - Unipex wrote:

>Jan Engelhardt ha scritto:
>>>My output chain:
>>>*filter
>>>:OUTPUT DROP [4831251:620928037]
>>>-A OUTPUT -o lo -j ACCEPT
>>>-A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
>>>-A OUTPUT -j LOG --log-prefix "Firewall DROPOUT- "
>>
>>So what's left is INVALID packets.
>
>Seem that a rule that drop the INVALID packets to the trick. But... 
>drop or reject the invalid packets?

Whatever fits your need.

>>>The question. Why I see this log and why my fw want to talk with 
>>>external and, the last, why the kernel double log talk and one is 
>>>inside the brackets [ ]?
>>
>>Because those are the contents of the ICMP packet. See the RFC.
>
>Append also with tcp, no only icmp.
>P.s. Have you a rfc number?

792

>And the last, have you also an rfc that explain why and where invalid 
>come from?

INVALID is a CT classification. RFC don't have much to do with that.

Re: strange log on gateway inside []

[Michele Petrazzo - Unipex]

Jan Engelhardt wrote:

Hi e thanks.

>>> And the last, have you also an rfc that explain why and where
>>> invalid come from?
> INVALID is a CT classification. RFC don't have much to do with that.

Pascal Hambourg wrote:
> ICMP port unreachable is not the natural reply to an unexpected TCP
> packet, so I guess it was generated by a REJECT target in the INPUT
> or FORWARD chain. If the original packet was in the INVALID state
> (or UNTRACKED if you used the NOTRACK target), then the ICMP error
> packet is in the INVALID state instead of RELATED.


A doubt.
Like said, INVALID is only a CT classification of my firewall. But,
since it's not a standard, how I can receive and reply (through my
FORWARD chain) to an INVALID packet? Who generate/classify it like
INVALID? My sender (I don't believe since it's not a standard) or my CT?

Thanks,
Michele

Re: strange log on gateway inside []

[Richard Horton]

On 30 July 2010 11:41, Michele Petrazzo - Unipex
<michele.petrazzo@unipex.it> wrote:
>
>
> A doubt.
> Like said, INVALID is only a CT classification of my firewall. But,
> since it's not a standard, how I can receive and reply (through my
> FORWARD chain) to an INVALID packet? Who generate/classify it like
> INVALID? My sender (I don't believe since it's not a standard) or my CT?
>

Your connection tracker...


-- 
Richard Horton
Users are like a virus: Each causing a thousand tiny crises until the
host finally dies.
http://www.pbase.com/arimus - My online photogallery
http://www.richardhorton.info

Re: strange log on gateway inside []

[Jan Engelhardt]

On Friday 2010-07-30 12:41, Michele Petrazzo - Unipex wrote:
>>>>invalid come from?
>>INVALID is a CT classification. RFC don't have much to do with that.
>
> Pascal Hambourg wrote:
>>ICMP port unreachable is not the natural reply to an unexpected TCP 
>>packet, so I guess it was generated by a REJECT target in the INPUT or 
>>FORWARD chain. If the original packet was in the INVALID state (or 
>>UNTRACKED if you used the NOTRACK target), then the ICMP error packet 
>>is in the INVALID state instead of RELATED.
>
>Like said, INVALID is only a CT classification of my firewall. But, 
>since it's not a standard, how I can receive and reply (through my 
>FORWARD chain) to an INVALID packet?

By not blocking it, standard processing will take place.

>Who generate/classify it like INVALID? My sender (I don't believe since 
>it's not a standard) or my CT?

The sender creates it, your firewall classifies it.