Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Firewalls Community


ASA "Deny TCP (no connection)" between on-prem client and AWS VM

I'm in the process of setting up a management console (MC) in AWS to manage a bunch of PCoIP clients in our office. The networking between our AWS private cloud and our on-prem infrastructure is sound because everything else works. The MC virtual instance itself - for the purposes of testing - has all traffic allowed to and from the office. We have other virtual instances in AWS that communicate with on-prem infrastructure totally fine with far more restrictions than the MC currently has.

On-prem, we have an ASA 5512 (9.6) with a site-to-site VPN set up that bridges the two networks. We have ACL rules for other cloud infrastructure to allow communication between the two networks that works fine, but for testing purposes we have allowed all traffic to and from the MC and our on-prem network.

On the MC, I am trying to run a discovery task to discover the PCoIP clients. When I run this task on a target IP (a single PCoIP) client, I get the below 5 lines in the logs, with the "Deny TCP (no connection)" being the final entry, the PCoIP client does not appear in the MC.

6 Jul 09 2019 08:58:59 302013 41082 5172 Built inbound TCP connection 93401627 for outside: ( to inside: (
6 Jul 09 2019 08:59:00 302013 64476 5172 Built outbound TCP connection 93401628 for outside: ( to inside: (
6 Jul 09 2019 08:59:00 302014 5172 64476 Teardown TCP connection 93401628 for outside: to inside: duration 0:00:00 bytes 4358 TCP FINs from inside
6 Jul 09 2019 08:59:10 302014 41082 5172 Teardown TCP connection 93401627 for outside: to inside: duration 0:00:10 bytes 2740 TCP FINs from inside
6 Jul 09 2019 08:59:10 106015 5172 41082 Deny TCP (no connection) from to flags RST on interface inside

We've triple checked the AWS side of things and are quite confident that there's nothing there that could be stopping this from working, so it must be something to do with the ASA.

We've tried configuring TCP State Bypass, and although we don't get the "Deny TCP" issue with it (we do get a bunch of TCP state bypass logs instead), it doesn't solve our problem. Turning on sysopt connection timewait results in no "Deny TCP" logs either, but again does not solve our problem.

Currently at a loss as to what could be preventing my PCoIP clients from being discoverable in the MC...

Hopefully someone here can point me in the right direction!




Everyone's tags (5)
VIP Advisor

Re: ASA "Deny TCP (no connection)" between on-prem client and AWS VM

These are normal messages. Whats happening that the application sends FIN
which ASA forwards and tears down the connection. Some applications respond
to FIN with RST as in your case. Because ASA terminated the connection with
FIN, when RST is received ASA will drop it because there is no existing
connection and RST flag can't be accepted as first message seen.

Re: ASA "Deny TCP (no connection)" between on-prem client and AWS VM

I appreciate the explanation, but unfortunately it doesn't solve my problem of PCoIP clients not appearing in my management console. Maybe the two things are unrelated, but at the moment I'm not inclined to believe so.

Incidentally, I discovered the ASDM Packet Tracer tool and tried running some tests using it.
Starting with the "inside" interface, if the source is and the destination is, my packet gets from inside to outside fine. But if I choose the "outside" interface and reverse the source and destination addresses, my packet gets dropped at the second "ACCESS-LIST" step by "Config: Implicit Rule".
On the Access Rules page, my inside rule is set up as "any" source to "any less secure networks" destination ("Implicit rule: Permit all traffic to less secure networks"), set to "Permit". I don't have an outside implicit rule. There's one global implicit rule at the bottom of the Access Rules list "any" source to "any" destination, set to "Deny".

My inside interface has security level 100, and my outside interface has security level 0. Not sure if it makes much difference, since everything else appears to be working.

I wonder if something to do with the above configuration could be causing my issue?