Buy or Renew
Buy or Renew
cancel
Turn on suggestions
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
Bookmark
|
Subscribe
|
37583
Views
0
Helpful
13
Replies

SYN Timeout

jeanaguemon
Level 1
Level 1

‎01-06-2009 12:29 PM - edited ‎03-11-2019 07:33 AM

I'm getting "SYN Timeout " message in my syslog when a user is trying to ssh to a server behind a firewall and getting denied. The hit count for the access-list is increasing every time he tries. The route and the translation are both configured. However, when on the same network as the server, he can connects fine. What this could be? Anyone experienced this before ? Thanks for your help.

2 people had this problem
Labels:
0 Helpful
13 Replies 13

jj27
Spotlight

‎01-06-2009 12:57 PM

The route back to the user is not defined, or going somewhere else.

The connection is being started through the firewall, but the response from the server never gets back to the firewall. This is common if it is a VPN user or VPN subnet.

Make sure in your core routing device you have some sort of IP route installed to route the source network back to the ASA.

0 Helpful

jeanaguemon
Level 1
Level 1
In response to jj27

‎01-07-2009 05:42 AM

The server in question is plugged into a layer 3 switch,which is plugged into the firewall. There is a default route in the switch pointing to the firewall. So I do have a route back to the user. In the meantime, there is another server on the same subnet, which can be accessed thru SSH from th same user. By the way, those two servers ae UNIX if this can help narrow down the problem. Thanks.

0 Helpful

edusmartnet
Level 1
Level 1
In response to jeanaguemon

‎01-07-2009 05:56 AM

Is the default gateway on the problem server the same as on the working server?

0 Helpful

jj27
Spotlight
In response to edusmartnet

‎01-07-2009 06:54 AM

Fundamentally, TCP/IP traffic and the routing of that does not care what OS the system is on :) It's all layer 3.

I'm guessing edusmartnet is right. The default gateway of the server is pointing to something else, perhaps.

0 Helpful

jeanaguemon
Level 1
Level 1
In response to jj27

‎01-07-2009 07:05 AM

The default gateway is same on both servers. I just doublechecked the TCP/IP settings on both servers.

0 Helpful

jj27
Spotlight
In response to jeanaguemon

‎01-07-2009 07:22 AM

Please provide us with the following information:

The source IP address (user trying to SSH to it)

The IP Address of the server

The default gateway of the server

Layer 3 Switch Configuration

Firewall Configuration

Strip out any usernames, passwords, and public IP information in the configurations.

0 Helpful

jeanaguemon
Level 1
Level 1
In response to jj27

‎01-07-2009 09:38 AM

Unfortunately, I cannot provide you with the config. files of the switch and the firewall due to the environment I'm working. I will loose my job by doing so. If you cannot think of anything else, which could cause the problem, that is fine. Thanks for your help.

0 Helpful

jj27
Spotlight
In response to jeanaguemon

‎01-07-2009 10:14 AM

It is definitely a routing issue. That's all that I personally can tell you without more information.

The RETURN traffic FROM the server is NEVER getting back to the firewall, aka SYN timeout.

Work on that. Do a traceroute from the server to the source IP address (user) from the server that he CAN access vs. the server that he cannot access.

0 Helpful

jeanaguemon
Level 1
Level 1
In response to jj27

‎01-07-2009 01:18 PM

When I traceroute from the working server, it goes thru the gateway and then some asteriks then the user. From the non working server, it goes thru the gateway and the user just one hop, see below

traceroute to 10.69.23.20 (10.69.23.20), 30 hops max, 40 byte packets

1 (10.69.190.20) 0.830 ms 0.515 ms 10.200.1.254 (10.86.

1.254) 0.673 ms

0 Helpful

jj27
Spotlight
In response to jeanaguemon

‎01-07-2009 01:26 PM

Ok, so what is the 10.200.1.254 address?

The connection is obviously stopping there.

What if you traceroute from the user to the server?

0 Helpful

jeanaguemon
Level 1
Level 1
In response to jj27

‎01-07-2009 01:30 PM

10.200.1.254 is th gateway and 10.69.190.20 is the user IP - thanks. The user is gone now--I cannot trace from the user to the server.

0 Helpful

jj27
Spotlight
In response to jeanaguemon

‎01-07-2009 01:34 PM

Ok, is the 10.200.1.254 address the firewall that the connection is initiated through?

If it is not, login to that device and to a trace to the user (when there is another chance to) and see where that goes. If it does not work, check the routing for that network.

I have seen strange occurrences when there is a NAT issue too, but let's not dive into that until we figure out that it is not a routing issue (which I still believe it is.)

0 Helpful

michaelzahn
Level 1
Level 1
In response to jj27

‎01-26-2013 07:44 AM

I have a similar problem, as I have a ASA 5510 connected to a 4900 switch with VLANs. I have a outside interface and an inside interface on the ASA 5510 which routes traffic to the multiple VLANs on the 4900.  My issue is specifically one of my VLANs on the 4900 requires static Nat's to servers on that VLAN. I have run the static Nat on the ASA 5510 and have provided ACL's in respects to the translated public IP address to one of the servers on the VLAN.  I am able to get a ping response from an outside network to the public IP address, as well as from the server I am able to access the Internet and ping outside connections.

My problem is the fact that I am getting a build inbound and a tear down with a SYN timeout when trying to access port 443, and to further my dilemma from the outside I cannot access the servers webpage via 443.

The following shows the current logs from the ASA 5510 from my outside public IP address.

6Jan 26 201309:33:5075.192.121.22457470192.168.5.x443Teardown TCP connection 6822365 for outside:75.192.121.224/57470 to inside:192.168.5.x/443 duration 0:00:30 bytes 0 SYN Timeout

6Jan 26 201309:33:2075.192.121.22457470192.168.5.x443Built inbound TCP connection 6822365 for outside:75.192.121.224/57470 (75.192.121.224/57470) to inside:192.168.5.x/443 (98.191.75.237/443)

6Jan 26 201309:33:1275.192.121.224512192.168.5.x0Teardown ICMP connection for faddr 75.192.121.224/512 gaddr 98.191.x.x/0 laddr 192.168.5.x/0

6Jan 26 201309:33:1275.192.121.224512192.168.5.120Built inbound ICMP connection for faddr 75.192.121.224/512 gaddr 98.191.x.x/0 laddr 192.168.5.x/0


The outside network is 98.191.X.X my inside interface is one 192.168.255.x and the VLAN is 192.168.5.x

Once again I have no issues pinging/I CMP from an outside public address to the inside which shows it being natted to 192.168.5.x server. The problem seems to occur in the upper layer however I do have ACL's which allow this. Any help can be greatly appreciated.

access-list outside_access_in extended permit ip any host 98.191.x.x

access-list outside_access_in extended permit tcp any host 98.191.x.x

access-list outside_access_in extended permit tcp any host 98.191.x.x eq 993

access-list outside_access_in extended permit tcp any host 98.191.x.x eq https

access-list outside_access_in extended permit icmp any host 98.191.x.237

access-list outside_access_in extended permit object-group TCPUDP any host 98.191.x.x eq echo

access-list outside_access_in extended permit icmp any host 98.191.x.x echo-reply

static (inside,outside) 98.191.x.x 192.168.5.x netmask 255.255.255.255

csc-ssm# sh run | i 192.168.5.x

access-list Users_access_in extended permit ip host 192.168.5.x any

static (inside,outside) 98.191.x.x 192.168.5.x netmask 255.255.255.255

0 Helpful
Customers Also Viewed These Support Documents
Review Cisco Networking for a $25 gift card
Top