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

mrhcarlin · ‎07-09-2019

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 172.20.4.247 41082 192.168.255.150 5172 Built inbound TCP connection 93401627 for outside:172.20.4.247/41082 (172.20.4.247/41082) to inside:192.168.255.150/5172 (192.168.255.150/5172)
6 Jul 09 2019 08:59:00 302013 192.168.255.150 64476 172.20.4.247 5172 Built outbound TCP connection 93401628 for outside:172.20.4.247/5172 (172.20.4.247/5172) to inside:192.168.255.150/64476 (192.168.255.150/64476)
6 Jul 09 2019 08:59:00 302014 172.20.4.247 5172 192.168.255.150 64476 Teardown TCP connection 93401628 for outside:172.20.4.247/5172 to inside:192.168.255.150/64476 duration 0:00:00 bytes 4358 TCP FINs from inside
6 Jul 09 2019 08:59:10 302014 172.20.4.247 41082 192.168.255.150 5172 Teardown TCP connection 93401627 for outside:172.20.4.247/41082 to inside:192.168.255.150/5172 duration 0:00:10 bytes 2740 TCP FINs from inside
6 Jul 09 2019 08:59:10 106015 192.168.255.150 5172 172.20.4.247 41082 Deny TCP (no connection) from 192.168.255.150/5172 to 172.20.4.247/41082 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!

Thanks,

Matt

Mohammed al Baqari · ‎07-09-2019

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.

mrhcarlin · ‎07-10-2019

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 192.168.255.150 and the destination is 172.20.4.247, 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?

Thanks.