Flag SYN not necessarily state NEW?

Flag SYN not necessarily state NEW?

[Ing. Christian Ogris]

Good morning,

just wondering if the behavior i discovered yesterday on our iptables-
firewall is "ok":

I connect from Box A via SSH to Box B, where the firewall runs, and i
get the state "NEW" on the first packet.
Then - the first connection is still established - i connect AGAIN from
Box A to Box B and do NOT get the state "NEW" anymore. (So obviously
it's already accepted by the ESTABLISHED,RELATED -j ACCEPT rule).
Is this behavior correct?

Meaning that a (second, third, ...) connection to the firewall will 
never get the state "NEW" for the first packet when there IS already
a connection to the same port, from the same host?

	
		regards, Chris

Re: Flag SYN not necessarily state NEW?

[Jozsef Kadlecsik]

On Wed, 8 May 2002, Ing. Christian Ogris wrote:

> I connect from Box A via SSH to Box B, where the firewall runs, and i
> get the state "NEW" on the first packet.
> Then - the first connection is still established - i connect AGAIN from
> Box A to Box B and do NOT get the state "NEW" anymore. (So obviously
> it's already accepted by the ESTABLISHED,RELATED -j ACCEPT rule).
> Is this behavior correct?

No. But so far nobody has reported such an ill-behaviour. I assume
something is wrong in your setup/logging.

Regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
WWW-Home: http://www.kfki.hu/~kadlec
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Flag SYN not necessarily state NEW?

[Hard__warE]

>>On Wed, 8 May 2002, Ing. Christian Ogris wrote:
>> I connect from Box A via SSH to Box B, where the firewall runs, and i
>>get the state "NEW" on the first packet.
>> Then - the first connection is still established - i connect AGAIN from
>>Box A to Box B and do NOT get the state "NEW" anymore. (So obviously
>> it's already accepted by the ESTABLISHED,RELATED -j ACCEPT rule).
>> Is this behavior correct?

>No. But so far nobody has reported such an ill-behaviour. I assume
>something is wrong in your setup/logging.
>
>Regards,
>Jozsef



I have tested this as im running SSH ans as you can see hear in the print
out of my packets that
i dont even need a Established Related Rule for SSH from the Internet or
Internaly , this is handled
by IP_conntrack moddule and so on .. :-) .


(Notice My SSH Box has its own IP on the Firewall (yet i have still
restricted access to the box as only SSH)

Chain OUTPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source
destination

51 38424 ACCEPT     all  --  *      eth0    172.16.0.22
172.16.0.0/16

/> netstat -C

Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 yes-dave.dynamicacc:ssh 172.16.0.123:2867
ESTABLISHED
Active UNIX domain sockets (w/o servers)

&
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 yes-dave.dynamicacc:ssh 172.16.0.123:2872
ESTABLISHED
tcp        0      0 yes-dave.dynamicacc:ssh 172.16.0.123:2871
ESTABLISHED
tcp        0      0 yes-dave.dynamicacc:ssh 172.16.0.123:2867
ESTABLISHED
Active UNIX domain sockets (w/o servers)
Proto RefCnt Flags       Type       State         I-Node Path



when i connect the first time (have not logged on yet) my SSH server says
the connecttion is already
ESTABLISHED and not NEW , and thats the same for evey connection after this
. The reason behind this is
SSH needs to establish a ESTABLISHED connection to the server before any
data is correctly Encrypted .. :D

Re: Flag SYN not necessarily state NEW?

[Matthew Hellman]

> I have tested this as im running SSH ans as you can see hear in the print
> out of my packets that
> i dont even need a Established Related Rule for SSH from the Internet or
> Internaly , this is handled
> by IP_conntrack moddule and so on .. :-) .

I must not be understanding what you're saying here, because you definitely
need both a NEW and ESTABLISHED rule.   In fact, this should always apply
and I would be rather disappointed in netfilter if there were any
exceptions. Don't think you need a RELATED rule however (at least it seems
to function without one). FWIW to the original poster, I log incoming NEW
ssh connections and it has always worked and still does.  If I connect
twice, it logs it twice. kernel version: 2.4.18, iptables version: 1.2.6a.

Goodluck
Matt

Re: Flag SYN not necessarily state NEW?

[Chris]

Matthew Hellman wrote:
> I must not be understanding what you're saying here, because you 
> definitely need both a NEW and ESTABLISHED rule.   In fact, this should 
> always apply and I would be rather disappointed in netfilter if there 
> were any exceptions. Don't think you need a RELATED rule however (at 
< least it seems to function without one). FWIW to the original poster,
> I  log incoming NEW ssh connections and it has always worked and still 
> does.  If I connect twice, it logs it twice. kernel version: 2.4.18, 
> iptables version: 1.2.6a.

I have to excuse my question from 8.5., it was at a time where i just
started to play around with iptables (used ipchains before).
My posting came very delayed to this mailing-list (more than a month),
and in the meanwhile i can't "reproduce" this behaviour anymore. So i
think it was just a mistake on my side (wrong logging or whatever, some
mistake of a beginner :)).

		regards, Chris

Re: Flag SYN not necessarily state NEW?

[Jozsef Kadlecsik]

On Sat, 15 Jun 2002, Hard__warE wrote:

> >>On Wed, 8 May 2002, Ing. Christian Ogris wrote:
> >> I connect from Box A via SSH to Box B, where the firewall runs, and i
> >>get the state "NEW" on the first packet.
> >> Then - the first connection is still established - i connect AGAIN from
> >>Box A to Box B and do NOT get the state "NEW" anymore. (So obviously
> >> it's already accepted by the ESTABLISHED,RELATED -j ACCEPT rule).
> >> Is this behavior correct?
>
> >No. But so far nobody has reported such an ill-behaviour. I assume
> >something is wrong in your setup/logging.

> I have tested this as im running SSH ans as you can see hear in the print
> out of my packets that

There is no such printout in your mail. The output of netcat is not equal
with the output of the logs generated by the LOG target.

> SSH needs to establish a ESTABLISHED connection to the server before any
> data is correctly Encrypted .. :D

Sorry, you misunderstand the different levels. The encryption in any TCP
stream plays no role in the (connection) tracking of the TCP stream
itself.

Regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
WWW-Home: http://www.kfki.hu/~kadlec
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Flag SYN not necessarily state NEW?

[Geog Hofstetter]

hmm is it possible that (if u use target LOG) your syslog just shows up 
'blah: SYN packet received'
'last message repeatet 2 times'

;)


    >>On Wed, 8 May 2002, Ing. Christian Ogris wrote:
    >> I connect from Box A via SSH to Box B, where the firewall runs, and i
    >>get the state "NEW" on the first packet.
    >> Then - the first connection is still established - i connect AGAIN from
    >>Box A to Box B and do NOT get the state "NEW" anymore. (So obviously
    >> it's already accepted by the ESTABLISHED,RELATED -j ACCEPT rule).
    >> Is this behavior correct?
    

Re: Flag SYN not necessarily state NEW?

[Antony Stone]

On Sunday 16 June 2002 7:04 pm, Geog Hofstetter wrote:

> hmm is it possible that (if u use target LOG) your syslog just shows up
> 'blah: SYN packet received'
> 'last message repeatet 2 times'

I would hope not - both the Source Port and the TCP ID number should be 
different for the two connections, and since these are both included in the 
LOG output from netfilter, the messages would not be identical...

Antony.

>     >>On Wed, 8 May 2002, Ing. Christian Ogris wrote:
>     >> I connect from Box A via SSH to Box B, where the firewall runs, and
>     >> i get the state "NEW" on the first packet.
>     >> Then - the first connection is still established - i connect AGAIN
>     >> from Box A to Box B and do NOT get the state "NEW" anymore. (So
>     >> obviously it's already accepted by the ESTABLISHED,RELATED -j ACCEPT
>     >> rule). Is this behavior correct?