Wireless Access

We've got a really odd issue right now where our wireless networks (different SSID's) can't connect to the Square mobile payment solution website.  https://squareup.com/ca

Every other website is accessible via our wireless networks that I've tested, but not the Square website.  Even when connected to the internal wireless network in the same IP space as our hard wired computers, using the same DHCP server, DNS server, and gateway as the hard wired computers, the Square website still won't load.  Yet the Square website loads on every wired computer with absolutely no issues.  All traffic passes through the same firewall, and there's no blocks in place on the firewall.

The only thing I've really tried so far is restarting the virtual controller at the site where I first discovered this was an issue.  This didn't change anything.

I should also note that I've been successful at loading the Square website a couple times intermittently for seamingly no reason because I changed nothing, and then it becomes inaccessible again.

The annoying part is that nslookup provides the same IP as the hard wired computers do for the Square website, and I can ping the Square website from wireless clients and receive a reply.  By all accounts and the fact that we've never blocked this website, it should work.

Any ideas would be greatly appreciated!  Thanks in advance!

In the Instant AP, click on Edit to Edit the SSID you are having problems with.  Under the VLAN tab, is "Client IP Assignment"  "Network Assigned" or "Virtual Controller Assigned"?

On the Access Tab, is there anything configured?

@cjoseph wrote:

In the Instant AP, click on Edit to Edit the SSID you are having problems with.  Under the VLAN tab, is "Client IP Assignment"  "Network Assigned" or "Virtual Controller Assigned"?

On 2 SSID's, they're "Virtual Controller Assigned", and on the internal network, it's "Network Assigned". The same problem exists on each.

@cjoseph wrote:

On the Access Tab, is there anything configured?

---

On 2 SSID's, there's 2 rules. The first is to Deny access to the internal IP space, and the second is the default Allow any to all rule.

This has always worked fine, and these rules haven't been changed at all since they were set up a year ago. The problem only started happening a week or so ago with no changes as far as I can tell.

EDIT: One other interesting thing to note.  Temporarily, I had the Squareup.com website loading on one of the SSID's (I forget which one, but it was one of the non-internal ones; VC assigned).  I immediately thought "oh, awesome, it's working" and had one of the users take out a tablet with a Square plugged into it (tablet connected to the same wireless network) and try processing a payment.  The payment started to go through and then hung at "Authorizing...", and the user said it was taking much longer than it should.  Sure enough, I pulled out my phone and laptop (both on the same wireless network) and the Square website that had just worked was no longer loading.  Every other website?  Perfectly fine.

- Associate the client to an access point.

- Find out what access point the user is associate to and SSH into that access point (important that you are on the access point the user is on).

- Try to access the square website on that client

- When it fails, on the commandline of the access point type "show datapath session".  Collect that output and search for the ip address of your user.  If the Instant AP is blocking that traffic, there will be a "D" or deny  flag:

a036000000lBEjH-02i6000000Uhl8g# show datapath session

Datapath Session Table Entries

------------------------------

Flags: F - fast age, S - src NAT, N - dest NAT
       D - deny, R - redirect, Y - no syn
       H - high prio, P - set prio, T - set ToS
       C - client, M - mirror, V - VOIP
       I - Deep inspect, U - Locally destined
       s - media signal, m - media mon, a - rtp analysis
       E - Media Deep Inspect, G - media signal
       A - Application Firewall Inspect
RAP Flags: 0 - Q0, 1 - Q1, 2 - Q2, r - redirect to master, t - time based

Source IP         Destination IP  Prot SPort Dport Cntr Prio ToS Age Destination TAge  Flags 
----------------  --------------  ---- ----- ----- ---- ---- --- --- ----------- ---- ----- 
10.153.171.216    10.153.175.162  6    9100  63237 0    0    0   0   dev20       4    YA     
192.168.4.217     216.58.194.49   6    50433 443   4    0    0   6   local       2637 C      
216.12.248.66     10.153.173.218  17   514   514   0    0    0   1   local       31   FRY    
192.30.68.80      10.153.175.91   6    443   39142 0    0    56  6   dev32       1bd  T      
10.153.173.106    192.30.68.80    6    1027  443   0    6    46  2   local       d28f PT     

Thanks cjoseph.  Finally had a moment to test this out (it's been on my todo list for awhile).  The show datapath session command worked on the AP that my test device was associated with (although again, no device can access the Square website via wireless) and I could see my device's IP address listed and when I seached for all appearances of it in the output, I didn't see a single Deny flag anywhere.  So it looks like the rules themselves aren't blocking the connection.

When I attempt to connect to the https://squareup.com/ca website, the website just hangs at loading, it doesn't immediately fail.  I don't have the show datapath session output in front of me at the moment, but I do remember seeing a "Y" on one of those lines, which would have been no syn.  Our firewalls also show the connection attempt as incomplete, not blocked.  But no reason is ever given as to why the connection doesn't finish.  Yet on a wired connection on a machine in the exact same subnet, the connection succeeds and the website is accessible.

Again, I can ping the Square website, I can tracert the square website, but I can't load the square website via wireless (a couple times I've been able to, for seemingly no apparent reason, and then it fails again).

The only other thing I can think of is that the firmware on the AP's had been upgraded at around the time that this stopped working.  But since no access rules were changed in the networks, and no Deny flags are seen, I can't understand why that would affect anything.