Allow HTTPS TCP Traffic through ASA5525

[steel_bender]

Trying, through ongoing research and troubleshooting, to configure an ASA5525 running version 9.8(2) to allow bidirectional traffic from two ESXi 6.7 VMs from an UCS C240 M5 through the ASA to a remote server that “telnet <DNS Name> 443” from my laptop receives a response from, but not ping as it is configured to be restricted on the remote side, and that the two VMs currently have HTTPS access to through the COMM server switch the UCS is currently directly connected to.

Besides configuring the firewall to allow access for the additional required "mandatory” ports for ESXi as well as for LDAP port 636, I have started by just trying to configure and verify port 443 HTTPS bidirectional traffic from the UCS VMs through the firewall to the remote server but no access list and otherwise configuration variation on the firewall that I keep believing to be true from repeated research is allowing a successful telnet response from the firewall.

Attached is the current show run configuration of the ASA5525 with the following access lists that allows ICMP to work but not tcp,

access-list INBOUND extended permit icmp any any echo-reply
access-list INBOUND extended permit tcp host <Remote Server IP> host 172.18.151.0 eq https
access-list INBOUND extended permit tcp host <Remote Server IP> host 192.168.0.0 eq https
access-list OUTBOUND extended permit icmp any any echo
access-list OUTBOUND extended permit icmp any any time-exceeded
access-list OUTBOUND extended permit tcp host 172.18.151.0 host <Remote Server IP> eq https
access-list OUTBOUND extended permit tcp host 192.168.0.0 host <Remote Server IP> eq https

and results in,

ASA# packet-tracer input outside tcp 172.18.151.171 443 <Remote Server IP> detailed
Phase: 1
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 172.18.151.1 using egress ifc outside
Phase: 2
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:
Forward Flow based lookup yields rule:
in id=0x2aaac8bb82d0, priority=501, domain=permit, deny=true
hits=30, user_data=0x7, cs_id=0x0, reverse, flags=0x0, protocol=0
src ip/id=172.18.151.171, mask=255.255.255.255, port=0, tag=any
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
input_ifc=outside, output_ifc=any
Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule
ASA#

and since I am unsure how to telnet for an ASA, also tried,

ASA# ping tcp
Interface: outside
Target IP address: <Remote Server IP>
Destination port: [80] 443
Specify source? [n]: y
Source IP address: 172.18.151.171
Source port: [0]
Repeat count: [5]
Timeout in seconds: [2]
Type escape sequence to abort.
Sending 5 TCP SYN requests to <Remote Server IP> port 443
from 172.18.151.171, timeout is 2 seconds:
?????
Success rate is 0 percent (0/5)
ASA#

and previously altered configuration to try with what I believe would be more specifically with,

access-list INBOUND extended permit tcp host <Remote Server IP> host 172.18.151.<cimc> eq https
access-list INBOUND extended permit tcp host <Remote Server IP> host 172.18.151.<vm1> eq https
access-list INBOUND extended permit tcp host <Remote Server IP> host 172.18.151.<vm2> eq https
access-list INBOUND extended permit tcp 172.18.151.171 255.255.255.0 any eq https
and may be more broadly with,
access-list INBOUND extended permit tcp any any eq https
access-list INBOUND extended permit tcp 172.0.0.0 255.0.0.0 any eq https
access-list OUTBOUND extended permit tcp 172.0.0.0 255.0.0.0 any eq https
with neither giving favorable results.

So any feedback that may provide further clarity about progressing through this issue would be greatly appreciated.

 

[Mogles49]

You likely are missing the outside nat. If you have these rules configured , and you are getting blocked by "implicit rule" this means something is missing besides ACLs. Also, i am suggesting to use an IP ACL for the beginning of your t-shooting. In my past experience, rules given were not enough specially dealing with vmware and AD authentication. You will be chasing your tail. Get it running first, then lock it down.