+ Reply to Thread
Results 1 to 8 of 8
  1. Senior Member
    Join Date
    Nov 2012
    Posts
    242
    #1

    Default Syn Timeout on FWSM/Firewall explained?

    Oke, I'm see ing the following happening in the logging of my firewall:

    Jan 15 09:30:16 FWSM_Firewall %FWSM-6-302014: Teardown TCP connection 145183634424206519 for ACCESS:TEST-10.0.0.1/1821 to Traffic:192.168.1.1/9519 duration 0:00:20 bytes 66 SYN Timeout

    Does this means That device 10.0.0.1 is able to reach 192.168.1.1, but there is no reaction, hence the SYN timeout?

    Also I have another question about GREP. I'm issueing the following command to see the flow between both IP addresses: cat logfile | grep "10\.0\.0\.1" | grep "192\.168\.1\.1" Can I do this quicker? With other words, can I shorten this command?
    Reply With Quote Quote  

  2. SS -->
  3. Resident Underachiever EdTheLad's Avatar
    Join Date
    May 2005
    Location
    Globe trotter, nfa
    Posts
    2,116

    Certifications
    CCNP/CCIP/IE Written
    #2
    I would imagine it means 10.0.0.1 has sent a tcp syn packet to 192.168.1.1, the FW has recorded seeing this syn packet and added the stateful request to its database waiting to receive an ack from 192.168.1.1, since no ack was received the stateful session info was dropped. This does not tell you anything in regards to the ip connectivity between server and host.
    Networking, sometimes i love it, mostly i hate it.Its all about the $$$$
    Reply With Quote Quote  

  4. Senior Member
    Join Date
    May 2014
    Posts
    168

    Certifications
    A+, Linux+, CCENT, Security+,CCNA:R/S,CCNA:S
    #3
    Quote Originally Posted by FrankGuthrie View Post
    Oke, I'm see ing the following happening in the logging of my firewall:

    Jan 15 09:30:16 FWSM_Firewall %FWSM-6-302014: Teardown TCP connection 145183634424206519 for ACCESS:TEST-10.0.0.1/1821 to Traffic:192.168.1.1/9519 duration 0:00:20 bytes 66 SYN Timeout

    Does this means That device 10.0.0.1 is able to reach 192.168.1.1, but there is no reaction, hence the SYN timeout?

    Also I have another question about GREP. I'm issueing the following command to see the flow between both IP addresses: cat logfile | grep "10\.0\.0\.1" | grep "192\.168\.1\.1" Can I do this quicker? With other words, can I shorten this command?
    Are you able to use awk? Cause, awk is your best friend:

    awk '/10\.0\.0\.1/ && /192\.168\.1\.1/ { print }' logfile
    Reply With Quote Quote  

  5. Senior Member
    Join Date
    Nov 2012
    Posts
    242
    #4
    Quote Originally Posted by EdTheLad View Post
    I would imagine it means 10.0.0.1 has sent a tcp syn packet to 192.168.1.1, the FW has recorded seeing this syn packet and added the stateful request to its database waiting to receive an ack from 192.168.1.1, since no ack was received the stateful session info was dropped. This does not tell you anything in regards to the ip connectivity between server and host.
    So this means that when the 3-way handshakes has begun from 10.0.0.1 (SYN), and 10.0.0.1 is not receiving the SYN ACK back from 192.168.1.1? Also I agree this says nothing about IP connectivity, but I think the next step is to check the path from 192.168.1.1 to 10.0.0.1, correct?

    Quote Originally Posted by Pupil View Post
    Are you able to use awk? Cause, awk is your best friend:


    awk '/10\.0\.0\.1/ && /192\.168\.1\.1/ { print }' logfile

    That works, but for now I find it to takes longer instead of using GREP twice, not sure if it will help me with shortening the command.
    Reply With Quote Quote  

  6. Netlurker cisco_trooper's Avatar
    Join Date
    Aug 2007
    Posts
    1,420

    Certifications
    CCNP Security, ASA Specialist, Firewall Security Specialist, IOS Security Specialist, IPS Specialist, VPN Security Specialist
    #5
    Get a wireshark or tcpdump going on 192.168.1.1. If you don't see the syn packet arrive you know the problem is the path. If you do see the syn packet you'll need to check to see if the 192.168.1.1 actually responded. If it does respond why doesn't the ack make it back. If it doesn't respond does 192.168.1.1 actually have a service running.
    Reply With Quote Quote  

  7. Senior Member
    Join Date
    Nov 2012
    Posts
    242
    #6
    Thanks guys for the help and suggestions.
    Reply With Quote Quote  

  8. 1337sauce
    Join Date
    Jul 2011
    Location
    Ze South
    Posts
    1,539

    Certifications
    BS, Linux+, Security+, LPIC-1, MCSE Server 2012, MCSE Desktop, MCSA Server 2008, MCTS 70-[415,681], MCTS 74-409, VCA-DCV, Novell CLA/DCTS/CNS, HDI CSR
    #7
    Quote Originally Posted by FrankGuthrie View Post
    That works, but for now I find it to takes longer instead of using GREP twice, not sure if it will help me with shortening the command.
    On an aside just do

    grep '10.0.0.1\|192.168.1.1' logfile

    There's no need to cat to grep and you can chain greps together which is faster than grep'ing to grep
    Reply With Quote Quote  

  9. Senior Member
    Join Date
    Jun 2010
    Location
    West Chester, PA
    Posts
    377

    Certifications
    CISSP, F5 CSE:Security, CCNP:Security, CCNP:R&S, RHCE, MCSE: Server Infrastructure, MCITP:SA/EA, MCSE: Security, Security+, Project+
    #8
    Chaining greps is an OR operation, meaning "grep a\|b" will return lines matching A or B.

    Grep'ing to grep is an AND operation, meaning "grep a | grep b" will return lines matching a and b.

    If you are trying to match a line containing both A & B and want the performance of only using one grep, then you need to be more specific in your grep match criteria. "grep -e a.*b" will return lines where a then b appears. If you wanted to also match lines with b then a, you could do "grep -e a.*b\|b.*a"
    Reply With Quote Quote  

+ Reply to Thread

Social Networking & Bookmarks