Well spotted!

I had missed the subtly of that, focusing on the fact that *something* was being received.

With the help of this info, I found that on the site, they had connected the LAN with the Internet (external) connection with a cable to the LAN on the inside.  As you would think, this gives unpredictable behavior at layer 2, and by purely good fortune it had been working until a reboot, where the re-ARPing resulted in the outside MAC address answering a request for the network address on the inside interface - hence how packets that should have returned to the inside interface appeared on the outside one instead.

Jennifer,

I'm sorry to hijack this topic but I have a similar situation:

VPN site to site

The ASA internal network 10.1.4.62 (this internal host is behind an MPLS network)

The remote network 201.44.112.113

Here I have an test, remote site trying to access the internal network

6    Nov 10 2010    09:30:44    106015    10.1.4.62    201.44.112.113     Deny TCP (no connection) from 10.1.4.62/401 to 201.44.112.113/25682 flags SYN ACK  on interface inside

VPN works, ping goes fine, but I have a problem with TCP

The difference here is that its really doing the 3 way handshake like this:

SYN: Outside --> Inside

SYN-ACK: Inside --> Outside

Can you please check the routing that 10.1.4.62 is actually being routed off the inside interface?

Jennifer,

Here is some piece of information:

interface GigabitEthernet0/1

nameif outside

security-level 0

ip address (public-address)  255.255.255.240 standby (public-address)

!

interface GigabitEthernet0/2

nameif inside

security-level 100

ip address 10.1.1.5 255.255.252.0 standby 10.1.1.6

!

......

!

route outside 0.0.0.0 0.0.0.0 (public-address) 1
route inside 10.0.0.0 255.0.0.0 10.1.1.1 1

Its been routed to the inside interface.

(ASA only has 2 interfaces working, and that is all the routing)

10.1.1.1 1 -> internal core & gateway (has routes configured correctly, to every MPLS network it points to the MPLS router)

Thanks.

In that case, you might want to check if the TCP connection itself has timeout because of the delay in getting the SYN-ACK packet.

By default, the TCP incomplete timeout is 30 seconds.

Here is how it goes:

- ASA receives SYN, and place that in the connection table.

- If the ASA does not receive the SYN-ACK packets within 30 seconds, it will clear that particular connection.

- So if the SYN-ACK packet arrives at the ASA after the default timeout of 30 seconds, you will receive that error message of no TCP connection found.

The embryonic connection timeout of 30 seconds is to ensure that there is no stale incomplete connections in the ASA connection table.

Thank you

I'll try double that time,is there any other way to do it or only using the police-map set-connection ?

Is there a way that the MPLS can alter the packet some how that when it gets back to the ASA it rejects. I see that the source and dest. are correct but i dont know about the TCP sequencing information

The best thing to check is to run packet capture on the inside interface for both inbound and outbound connection between the 2 hosts.

That would tell you exactly what happen, and you can download the packet capture in pcap format and check it on wireshark/ethereal.

"police-map set-connection" is the only way to increase the embryonic timeout.

Hi Rodrigo/All,

I know this thread has been updated a long time ago but I am facing similar issue and wanted to see what was done. Were you able to get it resolved? Was it an issue with route or access-list?

Thanks,
Jake