Thanks for your response, heres what we found from the datapath session capture. In this test, both target (10.43.8.120) and scanner (10.43.1.195) were on an allow all ACL profile.
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
L - ALG session
O - Session is programmed through SDN/Openflow controller
p - Session is marked as permanent
h - Https redirect error page
X - Http/https redirect for dpi denied session
RAP Flags: 0 - Q0, 1 - Q1, 2 - Q2, r - redirect to conductor, t - time based, i - in flow
Flow Offload Denylist Flags: O - Openflow, E - Default, U - User os unknown, T - Tunnel
R - L3 route
Source IP Destination IP Prot SPort Dport Cntr Prio ToS Age Destination TAge Packets Bytes Flags Offload flags
10.43.1.195 10.43.8.120 17 3283 3283 0 0 0 1 dev28 33 1 5e FA
10.43.8.120 10.43.1.195 17 3283 3283 0 0 0 1 dev28 33 1 5e FCA
10.43.8.120 10.43.1.195 6 5900 49608 0 0 40 0 dev8 185 83b 22fdb4
10.43.1.195 10.43.8.120 6 49608 5900 0 0 40 0 dev8 185 33d d0e6 C
10.43.1.195 10.43.8.120 17 3283 3283 0 0 0 1 dev28 4a 1 5e FA
10.43.8.120 10.43.1.195 17 3283 3283 0 0 0 1 dev28 4a 1 5e FCA
10.43.8.120 10.43.1.195 6 5900 49608 0 0 40 0 dev8 19c 84f 23177e
10.43.1.195 10.43.8.120 6 49608 5900 0 0 40 0 dev8 19c 351 d4f6 C
10.43.8.120 10.43.1.195 1 30728 0 0 0 0 0 dev8 1f 1 54 FI
10.43.8.120 10.43.1.195 6 5900 49608 0 0 40 0 dev8 1dd 892 236c24
10.43.1.195 10.43.8.120 1 30728 2048 0 0 0 1 dev8 1f 1 54 FCI
10.43.1.195 10.43.8.120 6 49608 5900 0 0 40 0 dev8 1dd 390 e1c2 C
Once we switched the target to our captive portal ACL, no records of both IPs were shown even after allowing the scanner IP and ports. Here is what it looks like on my ACL, I have also tried specifically allowing 10.43.1.195 with no change in behaviour.
Original Message:
Sent: Apr 08, 2024 03:30 AM
From: Herman Robers
Subject: MacOS Remote Desktop Scanner Unable to Update OS Version Information of Clients connected with Captive Portal Profile
The article you refer to does not show the direction of the traffic. If your scanned tries to reach a client on port 5900 while the client is connected to that captive portal, you may need to allow that traffic as well in your policy, like: 'scanner-ip -> any port 22,3283,5900'.
Probably easiest is to check what traffic is blocked/dropped through a show datapath session on the controller (assuming this is a controller based deployment); and then allow that traffic.
------------------------------
Herman Robers
------------------------
If you have urgent issues, always contact your Aruba partner, distributor, or Aruba TAC Support. Check https://www.arubanetworks.com/support-services/contact-support/ for how to contact Aruba TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.
In case your problem is solved, please invest the time to post a follow-up with the information on how you solved it. Others can benefit from that.
Original Message:
Sent: Apr 05, 2024 12:20 AM
From: james_c
Subject: MacOS Remote Desktop Scanner Unable to Update OS Version Information of Clients connected with Captive Portal Profile
The 3 devices above are assigned with an enforce captive portal AP Profle while the rest are assigned with an allow all profile. My CP AP Profile is already configured to allow ports listed in this link. TCP and UDP port reference in Remote Desktop
| Apple Support |
remove preview |
|
|
Any idea on whats going on?
