AWS Workspaces port 4172 through ASA 8.2

tahscolony · ‎07-16-2015

OK, this one has me stumped. Trying to connect the client to work spaces, it needs access to port 4172 for TCP and UDP. I have the Inside ACL allowing access to 4172, I see hits, I see the packet come in, but thats it. I can't see if it is translating.

However, if I switch to the guest network, which runs through a different firewall on 8.4 code, it works just fine. The problem appears to be the firewall, and I can't seem to find the issue.

Here is a capture showing the packets.

56: 15:49:55.403467 192.168.43.24.51751 > 54.173.124.226.4172: S 913847066:913847066(0) win 8192 <mss 1260,nop,wscale 8,nop,nop,sackOK>
57: 15:49:56.417474 192.168.43.24.51752 > 54.173.124.226.4172: S 2446962769:2446962769(0) win 8192 <mss 1260,nop,wscale 8,nop,nop,sackOK>

Here is what I see on the working ASA.

6|Jul 16 2015|14:51:57|302013|10.111.100.175|65522|54.173.124.226|4172|Built outbound TCP connection 188022257 for outside:54.173.124.226/4172 (54.173.124.226/4172) to dmz_guest:10.111.100.175/65522

Here is another puzzling thing, in ASDM logging, which is where the above came from, on the other ASA I do not see any 4172 transactions, I only see them when I do a CLI capture. I also do not see them when I do a packet capture wizard through ASDM.

We have a WSA, but my IP bypasses it completely and a grep on both WSA shows no transactions from my PC. It is as though it is not translating 4172. A show xlate local for my IP does not show any xlate for 4172.

prateek.verma · ‎07-16-2015

Hi,

Could you provide the output of "show asp drop | in 54.173.124.226" if the packet would be dropped by the firewall it would come under asp drops.

Regards,

Prateek Verma

tahscolony · ‎07-17-2015

That's the command I can never remember. It appears that it is not being dropped, as it is coming up empty. I opened a TAC case on this as we believe the ASA is redirecting it, but its being lost in the ether(net). The fact we are not seeing a return from the outside server means that is either not being translated, or is being redirected to the Ironports, which are ignoring them.

tahscolony · ‎07-17-2015

OK I discovered why its not translating the port. Back about a month ago, prior to testing, we decided to redirect the port to WSA, then use transparent redirection, which turned out to not be the proper method, and so removed 4172 from the redirect ACL. However, the service for the redirection has latched onto the port and wont release it.

WCCP service information definition:
   Type:          Dynamic
   Id:            80
   Priority:      240
   Protocol:      6
   Options:       0x00000012
   --------
        Hash:      DstIP
        Alt Hash: -none-
        Ports:     Destination:: 4172 8080 0 0 0 0 0 0

So this is why its not working, but now have to find out how to remove the port without rebooting the ASA or disrupting traffic in any way.