Users behind ASA 5525 cannot access Sonicwall Netextender login page via browser

[garry.holmberg1]

We have verified that users behind our ASA 5525 are unable to reach a remote site's Sonicwall Netextender via our outside internet connection.

Users get browser message "This site can't be reached" after it appears to timeout.  

This result is the same whether we have the user on our inside VLAN with ASA inside ACL in play, or we put them on a special test network on its own ASA interface with internet only access.  

If we connect via any other means from the same work computer e.g, smartphone hotspot (different ISP, ASA no longer in equation), or from user's home the connection to the Sonicwall Netextender works without issue.  Same browser.

The Sonicwall port for the Netextender is set to 4433, but SonicWall admin is willing to change if it needed.

I believe our tests would indicate that the issue isn't ACL related since the special internet only VLAN produced the same result. 

Yet, since connection to SonicWall works from elsewhere, it does appear that some other part of our ASA configuration is responsible for the inability to connect to the Sonicwall Netextender login page.

Our ASA is connected to Comcast EDI. 

Packet capture comparisons show that the successful connection involved TLSv1.2 only.  But the unsuccessful connection eventually has some spurious SSL packets "[TCP Previous Segment not captured] , Continuation Data" minus the quote marks in Info column.

Thank you,

Garry

[Alan Ng'ethe]

What do your ACLs look like? Do you have any inspections going on?

[garry.holmberg1]

Hi Alan,

We have resolved the problem, it wasn't on our end (ASA).  We are left wondering why the problem occurred, and what part of the solution actually fixed it.

The admin of the Sonicwalls in question took three actions, once we proved via Wireshark captures, that errors were associated with the webpage found at port 4433.  Webpage at 443 had no such communication errors.

The SonicWall admin, configured the Sonicwall's router facing interface to static IP, previously it was set to DHCP.  He added Google DNS server to the DNS server list, and he changed the MTU to something less than 1500.  I think he said 1428, but to be honest that may not be the exact number.

And poof, the webpage at 4433 now came up!

Why it stopped working in the first place we don't know.  Why these changes were chosen, or why they worked we don't know.

But, we believe the ASA was much more sensitive to the communication problems we were seeing in the Wireshark capture, while laptop firewall was much more tolerant of the communication errors and the TCP state table remained intact.

We are going to consider this issue resolved.

Thanks for your reply!

Garry

[Alan Ng'ethe]

Thanks for the update. This may help someone one day!