Airwatch issue Session Browser Query

a.jones — Tue, 25 Jun 2019 14:55:54 GMT

Hi All,

Just a sanity check question to ensure my config and thinking okay.

We are having issues with VMWare Airwatch traffic to a cloud server for a customer that migrated across to our network. They don't seem to be able to connect to the server for deployments. Traceroute to the server blackholes within VMWare environment. Test from other sources we can connect to the server.

My rule allows traffic from the client network out to the server IP on the required port using application airwatch, service as application default. This is patted out to the firewall interface with all other traffic. Logs show rule is being hit but application incomplete indicating the TCP handshake is not completing thereby matching the traceroute issue - no server connection.

If I look at the session browser I get this:

show session id 2700153

Session 2700153

c2s flow:
source: 10.119.77.16 [Public_99_Inside]
dst: 169.50.196.24
proto: 6
sport: 42319 dport: 443
state: INIT type: FLOW
src user: unknown
dst user: unknown

s2c flow:
source: 169.50.196.24 [Public_118_Outside]
dst: 185.111.131.198
proto: 6
sport: 443 dport: 49058
state: INIT type: FLOW
src user: unknown
dst user: unknown

Slot : 1
DP : 0
index(local): : 2700153
start time : Tue Jun 25 15:43:12 2019
timeout : 5 sec
total byte count(c2s) : 78
total byte count(s2c) : 0
layer7 packet count(c2s) : 1
layer7 packet count(s2c) : 0
vsys : vsys6
application : incomplete
rule : MKC Wifi-2
service timeout override(index) : False
session to be logged at end : True
session in session ager : False
session updated by HA peer : False
address/port translation : source
nat-rule : Internet Nat-1(vsys6)
layer7 processing : enabled
URL filtering enabled : False
session via syn-cookies : False
session terminated on host : False
session traverses tunnel : False
captive portal session : False
ingress interface : ae2.1530
egress interface : ae1.1521
session QoS rule : N/A (class 4)
tracker stage firewall : Aged out
end-reason : aged-out

Does the fact that there is an s2c flow indicate there is traffic coming back from the server or just effectively timeout traffic? It remains in State INIT and type FLOW - for me it's just due to it aging out and nothing to do with server connection.

Is there anything else that can be considered that I may have missed? I tried a 1-1 NAT and get the same results. In all cases we can only traceroute so far into VMWare to the server indicating they are blackholing our traffic for some reason. If I traceroute from my desktop, different network I can get to the server.

Thoughts or advice?

TIA

Adrian

Re: Airwatch issue Session Browser Query

BPry — Tue, 25 Jun 2019 17:58:17 GMT

@a.jones,

Your troubleshooting so far is sound and logical. Something is causing the traffic to be dropped silently, that could be intentional or it could be misconfigured routes.

Re: Airwatch issue Session Browser Query

a.jones — Thu, 27 Jun 2019 07:22:14 GMT

Thanks. We are chasing the remote end to get them to check the routing through their network.

Just wanted to ensure my thoughts were correct and I hadn't missed anything obvious.

Thanks

Adrian

topic Re: Airwatch issue Session Browser Query in General Topics

Airwatch issue Session Browser Query

Re: Airwatch issue Session Browser Query

Re: Airwatch issue Session Browser Query