Thursday, July 4, 2013

Subnet mask training made easy with a cisco router and cmd line

In this blog, I will show you a simple cisco trick, that will  help you understand  subnet masks.

1st some background, when I started  out with IP, all of the systems that I used  ( unix ) ,  display the netmask as as some FFFFFFF hex value.

Yes, 255.255.255.0  was represented as 0xFFFFFF00 , and 255.255.255.240 as 0xFFFFFFF0 and so on.

The old way of  quick counting was starting with a simple & common /24 & we all knew hexadecimal 0 -thru-F.

/25 = half of a /24
/26 = half of a /25 or a quarter of a /24
/27 = half of a /26 or 1/8 of a /24
/28 = half of a /27 or  1/16 of a /24
/29 = half of a /28 or 1/32 of a /24
and finally a /30 ....simple 4 address
If you don't know what a /32 is equal to, than skip this thread. You have major problems :)


Going smaller than a /24 prefix   ( less than  24 ) was also done in a similar way,  but now we following this approach;

/23 = 2x /24 ( 512 address )
/22 = 2x /23 or 4    /24s  ( 1024 address )
/21 = 2x /22 or 8    /24s  ( 2048 address )
/20 = 2x /21 or 16  /24s  ( 4096 address )

and so on.


So in my /15 that I will use later on & in this tutorial, that equals  512x  /24 or 2 /16 ( class B networks ) for a total of  131072 address.



See how easy that was?


Okay that might be strange approach nowadays, &  with the new generations of engineer, but  that was how us ole'school engineers started out.

1st  with understanding of Hex and  based  off a /24 ( class C ). The netmask, ultimately will determine your maximum size of  hosts for your network. So it's important to fully understand netmask.

Our current generation &  trends,  has the young engineers finding subnetting and /slash to decimal conversions very difficult. But in reality it's not.

If they would have started on a  Unix systems , this would probably have help these types of engineers learn subnetting & without no confusion imho.

I'm going to show you a cli trick that you can do to improve your   netmask  knowledge and training and it's only one simple commands  that anybody can do.


cli  terminal ip netmask-format

Okay let's execute this command on the cli and see what's our options;

terminal ip netmask-format  ?
  bit-count    Display netmask as number of significant bits
  decimal      Display netmask in dotted decimal
  hexadecimal  Display netmask in hexadecimal


Okay what does the above means?

bit-count =  /XX where  XX is the number of bits in the mask. A 255.255.255.0 would be respresented as /24 or 24 bits to form the mask.

decimal =  our standard 255.255.255.0 format ( that everybody comfortable with )

and finally   

hexadecimal  =  our 0xFFFFFF00 or what our earlier IP pioneers used to use :)

So let's say you are working on a router , and  using a netmask that you are not yet comfortable with. Or maybe your confused as to what the decimal dot format should be.  So let's say you have a /15
( who in the hell uses a /15 on a regular basis ?, unless your in a service provider role )

So you need to install a static route for that network,  and you have no clue as to what the mask should be, but you know what a  /16 ( class B network  255.255.0.0  ) or a /24 ( class C 255.255.255.0 ) should be, but  a /15 is odd & strange for you.

So let's change our  display type, &  to represent  /XX "bit-count".



 Okay now when we  show  our interfaces and  route  tables, it will display as a /XX format.


 Let's check it out,  by plumbing a few loopbacks  with different masks to see what I'm talking about.



Okay so let's check the bit /XX mask and see if we got /15 in  the above output ?




Nope, no /15 mask.

So we know the above  netmasks  combinations of  255.255.0.0 255.255.128.0 and 255.255.192.0 don't match a /15 netmask.

So now let's try a shorter netmask.



Bingo we got it. A /15 == a netmask of 255.254.0.0

Guess what? The route table will display the same.

Example1:


vrs  the decimal format



This is little trick can help you in a crunch & if your confused as to the netmask conversion. In reality, we should know all three methods and should know how to convert on our finger tips or a piece of paper.


Now for the grand finale, most unix systems still today display  hexadecimal and this is really a bummer for you  non hexadecimal speaking engineers :)

Here's one of my  BSD  cloud vm-machine;



So learn how to use Hex



Ken Felix
Freelance Network/Security Engineer
kfelix -at- socpuppets    insert-dot-here  com

   ^       ^
=( *    * )=
       o
    /     \

PPPoE IPv6 ( cisco )

In this blog, we will look at pppoe IPv6  between server+client using cisco routers.

Just like ipv4 we can support ipv6 clients and pppoe.  With IPCP supports  & ipv4,  & we have what's call IPV6CP for ipv6.




I did some work in the past with some guys in China and with pppoe connections using cisco routers. This configuration is straight forward and simple to deploy for PPPoEv6

PPPOE server+client  =  cisco 3825 15.1.X

show version | incl ersion
Cisco IOS Software, 3800 Software (C3825-ADVENTERPRISEK9-M), Version 15.1(4)M4, RELEASE SOFTWARE (fc1)
ROM: System Bootstrap, Version 12.4(13r)T, RELEASE SOFTWARE (fc1)


Dialup client details ;


ppp authentication PAP
username lab;
password lab


1st let's look at the server side of things;

pppoe client pool { ipv4 and ipv6 }

Okay very simple, we assign the pool that we will server clients from.

Next, here's the virtual-temp  configuration;


 key points up to point;

  1.  we have a /64 assignment for the pool
  2.  ipv6 is enable (virtual-interfaces )
  3.  ipv6 routing enable ( globally )
  4.  we have a ipv6 static address configured
  5.  and the username of "lab" with password "lab" ( in reality  you would used radius for a service provider  pppoe offerings )
  6. the virtual-template is set to  provide both ipv4|ipv6 address ( optional )
Okay now let's look at the client side of things. It too is straight forward and uses a dialer interface and the necessary ipv6 configurations.




Okay once again, we are rockin and rollin with a simple configuration


Okay, so let's see this in action.

I setup a  2001:db8:255::1 address on the loop0 of the pppoe-server. We will ping and conduct a traceroute to this address from the client.


High 5s




Ken Felix
Freelance Network/Security Engineer
kfelix --at--socpuppets   ---insert-a-dot--com

    ^       ^
=( @  @ )=
        o
      /    \

Thursday, June 27, 2013

I passed my Fortinet mail exam FCESP

This by far has been my hardest IT/exam ever , and much harder than the other  Fortinet exams that  I have taken over the course of 5 years. FCESP has straight forward questions  & on just  about everything you can imagine.

Unlike cisco certifications exams, the exam challenges you with both technical  questions and know how. They don't have silly  question such as;
  • what's cisco stance is.....
  • what's the methodology of.......
  • etc...

 The question ( 45 total ) are dealing with the FortiMAIL  unit  to include;  the operation, function and diagnostics capabilities.


I glad it's over, and  after my  1st miserable fail,  I'm just  glad I passed it & almost 2 years later.
( FCESP attempts )



The funny thing about this exam;

1: A FortiMail class is not going to help you at all ( so don't think you can pass, just by taking a class )
2: you will need  actually time deploying and managing these units
3: a lot of transparent-mode questions ( so get prepared )
4: same with almost all other parameters including  ldap,acl, recipient +ip based policies
5: no simple SMTP questions ( no give-me )
6: my exam was filled with a lot of things I 've never done or even knew  about ( :)  )
7: it's challenging
8: I thought I did much better, but the results showed otherwise


Good luck if you ever attempt to take this exam.


fwiw: The exam I took will be replaced in the near future per my email dialog with  Fortinet Certifications

e.g ( snapshot of  a response from Fortinet )


So if I want to get certified  for 5.0, I will have to take another exam.  I don't know how much harder it would be but ..... Boy I can't wait!

 :)

Ken Felix
Freelance Network/Security Engineer
kfelix    a t  hyperfeed  d o t  com



Wednesday, June 26, 2013

diag debug flow troubleshooting

In this blog, we will look at the FortiGate  diag debug  flow output messages & what they are trying to tell you.

I've been dabbing with Fortigates ever since 3.0 came out ( since 2005 ) and it still surprises me  on the pure amount of  individuals,  that struggles with diagnostics and those that don't even use the  diag debug flow.

In this post I'm going to show you some output messages and how to interpet them.

1st  up:

You try to ping , ssh or web into a fortigate and you are denied. Diag debug flow will show you something of the following;



So this means; " whatever interface your trying to access did now have the correct < set allowaccess> statement "

e.g ( webgui interface configurations )




or via the cli;



2nd:

This  message  below is "10 out of 10" times one of the following;



1: a deny firewall policy ( it even tells you so :) )
2: firewall policy missed-ordered or sequence#  ( our most specific and denys should be 1st in the order )
3: error in your firewall policy ( typo , wrong address, wrong  interface , service or a combination of erros )
4: or a missing firewall policy ( if it's not allowed it's denied )

Bottom line check your firewall policies and go thru them with a fine tooth comb.


3rd and final: ( my favorite )

When your working with  sslvpn or tunnels this is a common  error. It's also seen when you have internal LANs being routed behind another device like a internal router & you have no route for the source(s) in the FGT route table.


In the above 10 out of 10 times it's any of the following;

1: routes installed  incorrectly
2: no route installed ( it's missing )

Bottom line ;"your routing is screwed up" . Monitor your route table and validate the next-hop gateway is correct & the correct interface.




Diagnostics with diag debug flow is simple and straight.



It frustrate me to see  junior/senior  Fortigate engineers struggling to diagnostic connections problems, and they DON'T ever bother to use the built-in diagnostics tools or just bypass the process of making a packet capture.

The fortigate is one of the best firewalls on the market to trouble-shoot ( period ). You will not find anything as simple or as easy.

These commands should be routine in our everyday  activities and before you waste time throwing things into the mix;

diag debug flow
diag sniffer

And finally, we have  the means to make  packet  captures on most any newer fortigates.

 So instead of guessing, shoot-n-pray, or just using the "trial--n--error" process, start using the diag debug flow  cmds :)



Ken Felix
Freelance Network/Security Engineer
kfelix  ---a---t--- hyperfeed --d-o-t-- com

    ^        ^
=( @   @ ) =
         ~
      /     \

diag system session ( a quick way find sessions on fortigate firewalls )

In this post, I will share  with you a simple means; "  to find and for filter specific sessions"from the cmd line.

Fortigate offers a  session  count thru the gui, but it's not as flexible as what you can do from the command line. The cli provides more flexibility,  and in fact ; you can filter option in the webgui, but it's not as quick nor easy to  deploy.

If you need to quickly change filters, the cli is the best means.

( samples of the webGui  session details )







The diag system session  or session6 command, provides either the ipv4 or ipv6  sessions stats. With this command you can filter by a host of parameters. This allows you to zoom into the  sessions types that you might have interests in.

here's those parameters;



As you can see from the above, we have a host of parameters. In the case of the output above, I'm filtering for icmp ( protocol #1 )


A simple ping to my wan2 interface after allowance for ping, will display the session(s) with the above filter.





Filtering on sessions in this manner, allows for quick diagnostics of the total sessions  & helps with quickly identifying  states within your fortigate firewall.


You should get use to applying and clearing filters in your everyday  monitoring , and trouble-shooting activities.



To wrap up, the flexibility in the filter is amazing and with creativity, you can filter on a host fields. In this last snapshot; " here's a filter using just  the policyID"

( I highlighted some key items )




The session filters along with diag debug flow, are two of the most important diagnostic commands that we have. These commands, make the life of diagnostic for fortigate series firewalls, much easier. They are simple to deploy provide more details than most other brands ( cisco ASA, Juniper NS/SRX ) and the information is very useful.


Ken Felix
Freelance Network/Security Engineer
kfelix  at  hyperfeed  .....dot....com

   ^      ^
=( *  * )=
       o
      /  \

Sunday, June 23, 2013

SNMPv3 traps config + cisco

In this blog we will look at security SNMPv3 traps




SNMPv3 allows for us to generate traps and secure these between the agent and manager. To do this we need to take a few steps in  our configurations;

1st we need to enable traps

config t
  snmp-server enable traps

end

next we need to define  a snmpv3 group and a user. Here we are defining a group name <mygroup> and a user <myuser> and with  <md5> and single <des> for authentication and encryption.

config t
 snmp-server group mygroup v3 auth
 snmpserver user myuser  mygroup v3  priv md5 Ims0s3cur3d  des56 hAckm3123Wed
end


The next few steps are crucial; we have to have a unique EnginID, but we don't have to configured one. By default, our  snmpEngineID is predefined on every cisco  router/switch device.

This  ID is created by default , & by using the 1st physical interface bia ( burned in address  aka mac-address )

Here's a cisco 2800;

rt1.mdc11#show int gi 0/0 | incl bia
  Hardware is MV96340 Ethernet, address is 0015.fad8.2211 (bia 0015.fad8.2211


and check out our SNMPengine ID

rt1.mdc11#show snmp engineID       
Local SNMP engineID: 8000000903000015FAD2211  <------ here

Remote Engine ID          IP-addr    Port
 


Notice how our bia is used to compute the engine ID?

It's done by default and you have to do nothing. Arguments have been made for crafting the ID by and for it being unique for each device in your network.  A few valid reasons exist for this purpose;

etc.

  • Such as if you   change hardware ( i.e  RMA ) or configurations are move to a new device ( SNMP engine ID will change )

  • Also the  SNMPv3 user  password is hashed off this  ID. So if you change it mid-stream, it would  screw up the SNMPv3 user


Now moving on, you need to craft a remote snmp engine ID for the remote collector;

snmp-server engineID remote 192.0.2.1 8000000903000000000001

Once again this ID is unique and should be for the SNMPtrap collector.

Now that we have all of the ingredients,  we can complete the config by mapping the SNMPv3 user to our  snmp-server  hosts that's to receive the traps.

Here's the final configuration for our  user to send traps to the host 192.0.2.1; the user =  "myuser", and we are using  version 3.

e.g
snmp-server  host 192.0.2.1  informs  version  3 priv myuser


So  in this example, the  router/switch would send  snmpv3 traps with authentication only, and with no encryption. The SNMP collector would authenticate the sender traps.



The following dumps shows you some unencrypted traps being sent to a  collector & from the above host;






Here's some other important information that pertains to cisco and SNMPv3 users;

The SNMPv3 user information,  is NOT maintain in the running-config. If you "dir" the nvram filesystem, it would maintain a list of  SNMPv3 user names/password-hashes and along with  any ssh private-pub/keys. If you would run the "show run " command, you will not find any user information for SNMPv3.



NOTE: The file  <private-config> contains the SNMPv3 user  information and it is NOT read/write by anyone.

Also the "show snmp user" command will show you details about any  configured  users, along with your SNMP engine ID.


So SNMPv3 traps are easy to configure , and requires a few more steps. Its simple, and just remember ; " you have the means to use auth or authPriv between the  SNMPagent and collector"


Ken Felix
Freelance Network/Security Engineer

   ^     ^
=( *  * )=
       o
     /    \

Server "active close"

With a typical web-browser, the normal behavior is for the server to close the session after they have received the request via the client. But that's doesn't always happen in that order. In this post we will look at some closing for tcp-sessions.

Here's the opposite, where a server closes the session first;
( the client sits at 10.0.18.11 in these examples )

   
sh-3.2$ sudo tshark -r active*close.pcap -R 'tcp.port==55876'
 21 15.184532000  10.0.18.11-> 64.124.19.179 TCP 78 55876 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=16 TSval=816445360 TSecr=0 SACK_PERM=1
 22 15.286232000 64.124.19.179 -> 10.0.18.11 TCP 66 http > 55876 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1430 SACK_PERM=1 WS=128
 23 15.286279000  10.0.18.11-> 64.124.19.179 TCP 54 55876 > http [ACK] Seq=1 Ack=1 Win=262144 Len=0
 24 15.286337000  10.0.18.11-> 64.124.19.179 HTTP 205 GET / HTTP/1.1
 25 15.377931000 64.124.19.179 -> 10.0.18.11 TCP 60 http > 55876 [ACK] Seq=1 Ack=152 Win=6912 Len=0
 33 25.378766000 64.124.19.179 -> 10.0.18.11 TCP 60 http > 55876 [FIN, ACK] Seq=1 Ack=152 Win=6912 Len=0
 34 25.379010000  10.0.18.11-> 64.124.19.179 TCP 54 55876 > http [ACK] Seq=152 Ack=2 Win=262144 Len=0
 35 25.379271000  10.0.18.11-> 64.124.19.179 TCP 54 55876 > http [FIN, ACK] Seq=152 Ack=2 Win=262144 Len=0
 36 25.467514000 64.124.19.179 -> 10.0.18.11 TCP 60 http > 55876 [ACK] Seq=2 Ack=153 Win=6912 Len=0
sh-3.2$

I bold the line containing the FIN-ACK and from the direction of the server. Now let's compare the  normal TCP close typically done by a client.


-->
sh-3.2$ sudo tshark -r normalclose.pcap  -R 'tcp.port==56154'
  1 0.000000000  10.0.18.11-> 15.193.113.27 TCP 78 56154 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=16 TSval=816940518 TSecr=0 SACK_PERM=1
  2 0.044037000 15.193.113.27 -> 10.0.18.11 TCP 78 http > 56154 [SYN, ACK] Seq=0 Ack=1 Win=32768 Len=0 MSS=1380 SACK_PERM=1 WS=1 TSval=3823454198 TSecr=816940518
  3 0.044278000  10.0.18.11-> 15.193.113.27 TCP 66 56154 > http [ACK] Seq=1 Ack=1 Win=131328 Len=0 TSval=816940561 TSecr=3823454198
  4 0.044447000  10.0.18.11-> 15.193.113.27 HTTP 208 HEAD / HTTP/1.1
  5 0.151665000 15.193.113.27 -> 10.0.18.11 TCP 383 [TCP segment of a reassembled PDU]
  6 0.151972000  10.0.18.11-> 15.193.113.27 TCP 66 56154 > http [ACK] Seq=143 Ack=318 Win=131008 Len=0 TSval=816940667 TSecr=3823454209
  7 0.152167000  10.0.18.11-> 15.193.113.27 TCP 66 56154 > http [FIN, ACK] Seq=143 Ack=318 Win=131072 Len=0 TSval=816940667 TSecr=3823454209
  8 0.198413000 15.193.113.27 -> 10.0.18.11 TCP 66 http > 56154 [ACK] Seq=318 Ack=144 Win=32768 Len=0 TSval=3823454213 TSecr=816940561
  9 0.198646000  10.0.18.11-> 15.193.113.27 TCP 66 [TCP Dup ACK 7#1] 56154 > http [ACK] Seq=144 Ack=318 Win=131072 Len=0 TSval=816940711 TSecr=3823454213
 10 0.203468000 15.193.113.27 -> 10.0.18.11 HTTP 66 HTTP/1.1 200 OK
 11 0.203732000  10.0.18.11-> 15.193.113.27 TCP 66 56154 > http [ACK] Seq=144 Ack=319 Win=131072 Len=0 TSval=816940715 TSecr=3823454213
sh-3.2$
sh-3.2$


Notice the client  initializing the closure first? Also you see some duplicate ACK  that's not relevant.

Here's another client side closure;

-->
sh-3.2$ sudo tshark -r normalclose.pcap  -R 'tcp.port==56421' -tad
  1 2013-06-22 23:40:09.145392000  10.0.18.11-> 140.211.167.51 TCP 78 56421 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=16 TSval=817520647 TSecr=0 SACK_PERM=1
  2 2013-06-22 23:40:09.236713000 140.211.167.51 -> 10.0.18.11 TCP 74 http > 56421 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1380 SACK_PERM=1 TSval=2005662022 TSecr=817520647 WS=128
  3 2013-06-22 23:40:09.237021000  10.0.18.11-> 140.211.167.51 TCP 66 56421 > http [ACK] Seq=1 Ack=1 Win=131328 Len=0 TSval=817520736 TSecr=2005662022
  4 2013-06-22 23:40:09.237193000  10.0.18.11-> 140.211.167.51 HTTP 207 HEAD / HTTP/1.1
  5 2013-06-22 23:40:09.330093000 140.211.167.51 -> 10.0.18.11 TCP 66 http > 56421 [ACK] Seq=1 Ack=142 Win=15616 Len=0 TSval=2005662116 TSecr=817520736
  6 2013-06-22 23:40:09.331312000 140.211.167.51 -> 10.0.18.11 TCP 255 [TCP segment of a reassembled PDU]
  7 2013-06-22 23:40:09.331584000  10.0.18.11-> 140.211.167.51 TCP 66 56421 > http [ACK] Seq=142 Ack=190 Win=131136 Len=0 TSval=817520829 TSecr=2005662116
  8 2013-06-22 23:40:09.331977000  10.0.18.11-> 140.211.167.51 TCP 66 56421 > http [FIN, ACK] Seq=142 Ack=190 Win=131136 Len=0 TSval=817520829 TSecr=2005662116
  9 2013-06-22 23:40:09.428806000 140.211.167.51 -> 10.0.18.11 TCP 66 http > 56421 [FIN, ACK] Seq=190 Ack=143 Win=15616 Len=0 TSval=2005662210 TSecr=817520829
 10 2013-06-22 23:40:09.429067000  10.0.18.11-> 140.211.167.51 TCP 66 56421 > http [ACK] Seq=143 Ack=191 Win=131136 Len=0 TSval=817520925 TSecr=2005662210
sh-3.2$

Same here, the client sends the FIN-ACK and the server immediately sends back a FIN-ACK and doesn't even bother to  wait for the  client #2nd  ACK.


And lastly,  here's a  look at another client and server tear-down, once again initialized by the server;

   
sh-3.2$ sudo tshark -r normalclose.pcap  -R 'tcp.port==56155'
 12 6.023331000  10.0.18.11-> 156.151.59.35 TCP 78 56155 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=16 TSval=816946451 TSecr=0 SACK_PERM=1
 13 6.126083000 156.151.59.35 -> 10.0.18.11 TCP 78 http > 56155 [SYN, ACK] Seq=0 Ack=1 Win=4290 Len=0 MSS=1430 WS=1 TSval=1863626880 TSecr=816946451 SACK_PERM=1
 14 6.126398000  10.0.18.11-> 156.151.59.35 TCP 66 56155 > http [ACK] Seq=1 Ack=1 Win=131872 Len=0 TSval=816946553 TSecr=1863626880
 15 6.126548000  10.0.18.11-> 156.151.59.35 HTTP 209 HEAD / HTTP/1.1
 16 6.249165000 156.151.59.35 -> 10.0.18.11 HTTP 203 HTTP/1.0 301 Moved Permanently
 17 6.249460000  10.0.18.11-> 156.151.59.35 TCP 66 56155 > http [ACK] Seq=144 Ack=138 Win=131728 Len=0 TSval=816946674 TSecr=1863627001
 18 6.249666000 156.151.59.35 -> 10.0.18.11 TCP 66 http > 56155 [FIN, ACK] Seq=138 Ack=144 Win=4433 Len=0 TSval=1863627001 TSecr=816946553
 19 6.249714000  10.0.18.11-> 156.151.59.35 TCP 66 56155 > http [FIN, ACK] Seq=144 Ack=138 Win=131728 Len=0 TSval=816946674 TSecr=1863627001
 20 6.249827000  10.0.18.11-> 156.151.59.35 TCP 66 56155 > http [FIN, ACK] Seq=144 Ack=139 Win=131728 Len=0 TSval=816946674 TSecr=1863627001
 21 6.354273000 156.151.59.35 -> 10.0.18.11 TCP 66 http > 56155 [ACK] Seq=139 Ack=145 Win=4433 Len=0 TSval=1863627108 TSecr=816946674
 22 6.354555000  10.0.18.11-> 156.151.59.35 TCP 66 [TCP Dup ACK 20#1] 56155 > http [ACK] Seq=145 Ack=139 Win=131728 Len=0 TSval=816946777 TSecr=1863627108
 23 6.355058000 156.151.59.35 -> 10.0.18.11 TCP 66 [TCP Dup ACK 21#1] http > 56155 [ACK] Seq=139 Ack=145 Win=4433 Len=0 TSval=1863627108 TSecr=816946674
sh-3.2$

So a server can close the tcp connection 1st. 

TCP allows for either party to close the sessions.  When the server closes the session 1st ( by sending the initial FIN-ACK ) it's called a "active close". 

NOTE:  In the above last  pcap example,  and due to the short  delay between  packets #18 & #19, I believe this yet another close type, known as a   simultaneously close.


(  keep theses below thoughts in mind when dealing with  tcp )

All TCP sessions goes thru  these states;

  LISTEN ( server listening and awaiting for connections )
  SYN-SENT  ( a cliet Sending a request to Synchronize a session )
  SYN-RECEIVED ( server ack the client and completion of the Synchronize the session via sequence #s )
  ESTABLISHED ( client +server are actively establish, does not necessary mean we are passing data )
  FIN-WAIT1 ( awaiting a connection termination state or ack from the remote ) 
  FIN-WAIT2 ( awaiting a connection termination state from remote )
  CLOSE-WAIT ( awaiting a connection termination from the local machine )
  CLOSING (  a waiting a connection termination from the remote host )
  LAST-ACK ( ack of the last closing state)
  TIME-WAIT ( a state to ensure that the session is closed )
  CLOSED ( a psuedo state  it really doesn't exists  & means we are close and not sending data )
 


With the active close, this is acceptable and not bad behavior. The server does not have to wait for the  session to be torn down via the client or even the "Acknowledg" the client requests.

With a lot of tcp based applications  & those that deals with "web" services, the server may start the tear down 1st. So keep that thought in mind.

   ^   ^
=( * * )=
     / ` \

Ken Felix
Freelance Network/Security Engineer
kfelix  ---a--t--- hyperfeed  dot com