Flag SYN not necessarily state NEW?

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

default gateway problem.

[Kumar]

Hi , 

Have installed RedHat 7.2 ( kernel -2.4.7-10) with two nic's. One is having an internal IP and the other a public IP. 
There are no Ipchains/ IPtables rules nor there are any nating rules. 
Have enabled IP forwarding.  The default gateway of the internal IP is the public ip, right ? 

When some other machine is connected to the network giving the same ip, there is no problem. 
But when I do ping -b <broadcast address >  I get response from some of the host which are on the public ip on the same subnet. 
Have also edited the hosts file with the machine specification and have also edited the nsswitch.conf for files, dns. 
Have also checked for the broadcast address and the subnet mask displayed in the ifconfig command and everything seems to be ok. 
I have tried looking for irq conflicts in the logs, but didnt fine any. And assuming it has any irq conflicts then in that case the card should not 
function at all right ??

I am facing the following problems : 
a) The machine is not able to connect to the default gateway, but it can connect to other machines on the same subnet. 
      So it is not ale to connect to the internet, since it canot connect to the gateway. 
b) comand like route, netstat takes exceptionally long time to display the output.
     I know we can always do route -n to disable the dns lookup, bu in the other linux boxes it does nto take his much time.  

I had tried some commands before rebooting the mahine in iptables.Have rebooted the machine n number of times for various reasons after that. 
I have checked the rules by : iptables -L and iptables -t nat -L commands. 
Is there any other command to check if there are any rules , or any oher typ of firewll settings ??? 

What could be the problem ?

 Please help.

Thank you for your response and help in advance 
Warm regards, 
Kumar. 

***************************
Below is output of the the route and ifconfig commands. 

Please 

Here's the output of the ifonfig comand : 

eth0      Link encap:Ethernet  HWaddr 00:10:B5:0A:9F:C7  
          inet addr:192.168.0.6  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2119 errors:0 dropped:0 overruns:0 frame:0
          TX packets:64 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:255707 (249.7 Kb)  TX bytes:5301 (5.1 Kb)
          Interrupt:11 Base address:0xa000 

eth1      Link encap:Ethernet  HWaddr 01:00:21:DD:78:00  
          inet addr: x.x.x.x  Bcast:x.x.x.x  Mask:x.x.x.x          
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1927 errors:0 dropped:0 overruns:0 frame:0
          TX packets:238 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:244135 (238.4 Kb)  TX bytes:14454 (14.1 Kb)
          Interrupt:3 Base address:0xd000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:108 errors:0 dropped:0 overruns:0 frame:0
          TX packets:108 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:9662 (9.4 Kb)  TX bytes:9662 (9.4 Kb)

Here's the output of the route command : 

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use     Iface
x.x.x.x              *               x.x.x.x                 U         0      0        0         eth1
192.168.0.0     *               255.255.255.0   U         0      0        0         eth0
127.0.0.0       *               255.0.0.0              U        0      0        0         lo
default         x.x.x.x          0.0.0.0                 UG      0      0        0         eth1

*****************************************

Re: default gateway problem.

[Antony Stone]

On Saturday 15 June 2002 1:35 pm, Kumar wrote:

> Hi , 
> 
> Have installed RedHat 7.2 ( kernel -2.4.7-10) with two nic's. One is having
> an internal IP and the other a public IP. 
 There are no Ipchains/ IPtables
> rules nor there are any nating rules. Have enabled IP forwarding.  The
> default gateway of the internal IP is the public ip, right ? 

No, the default gateway of the internal LAN (I assume you meant the machines 
on the internal network) is the private (internal) IP of the firewall.

A gateway must always be an address on the local network of whatever machine 
you're talking about the gateway of.

> When some other machine is connected to the network giving the same ip,
> there is no problem.

Um, what do you mean by that ?   Two machines having the same IP address !?

> I am facing the following problems : 

> a) The machine is not able to connect to the default gateway, but it can
> connect to other machines on the same subnet. 
 So it is not ale to connect
> to the internet, since it canot connect to the gateway.

See my advice above.

> b) comand like
> route, netstat takes exceptionally long time to display the output. I know
> we can always do route -n to disable the dns lookup, bu in the other linux
> boxes it does nto take his much time.

I expect you've got an external DNS server listed, and because the gateway's 
not correct, the machine can't contact the DNS server.


> Here's the output of the ifonfig comand : 
> 
> eth1      Link encap:Ethernet  HWaddr 01:00:21:DD:78:00  
>           inet addr: x.x.x.x  Bcast:x.x.x.x  Mask:x.x.x.x          
>            UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:1927 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:238 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:100 
>           RX bytes:244135 (238.4 Kb)  TX bytes:14454 (14.1 Kb)
>           Interrupt:3 Base address:0xd000 
> 
> Here's the output of the route command : 
> 
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags Metric Ref    Use    
> default         x.x.x.x          0.0.0.0                 UG      0      0  
>      0         eth1 

Are the two sets of x.x.x.x the same here ?

If they are, then that's your problem, and I think I misunderstood you above 
- I assumed you were talking about the default gateway for a machine on the 
internal LAN (which sould be set to 192.168.0.6 in your case).

The default gateway for the firewall itself is your ISPs router - in other 
words, whatever is on the other end of the connection to eth1.

Hope this helps,

 

Antony.

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?

Re: [x] - Re: Flag SYN not necessarily state NEW?

[Geog Hofstetter]

jep right, didnt think so far ;)

then i think this phenomen is neither explainable nor believeable.
if a connection is going to be established 
first SYN is sent 
SYN,ACK is received
and ACK will be answered
(TCP three-way handshake)

i dont know any case where TCP-connections are established(!)
in other way

__
Georg


    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.