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?

Find more posts tagged with

Comments

EdTheLad

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.

Pupil

FrankGuthrie wrote: »

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

FrankGuthrie

EdTheLad wrote: »

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?

Pupil wrote: »

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.

cisco_trooper

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.

FrankGuthrie

Thanks guys for the help and suggestions.

lsud00d

FrankGuthrie wrote: »

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

apr911

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"