What might cause this error when trying to download a profile for the first time?
I receive the error when connecting from a domain-joined laptop to our Aruba Controller through a normal internet (non-domain) Wifi-connection.
If I connect from the internal (domain) network, the profile download works fine.
Once the profile is downloaded (through internal network), VIA works fine on the WiFi, also after reboots etc.
I've made a wireshark and noticed that on Wifi, the laptop sends a lot of domain-related DNS requests to the WiFi DNS server, which that DNS is unable to answer. When connecting through internal network, I don't see those DNS requests.
Is this a known issue? Can I fix it?
Tried disabling auto-upgrade and ssl-fallback, no difference. Tried an old VIA-client (2.3.4), made no difference. On the controller I only see logged that the client succesfully authenticates, but after that, nothing. Port 443/4500 are open from the internet.
PS: everything has been working fine for years. Not sure when this error started. We only noticed now that we have new laptops/users that need to download a profile for the first time.
I'm not sure what you mean? The VIA Pool is indeed part of the company local subnet if that's what you mean.PS: if I connect from a non-domain joined computer through wifi, everything is fine as well, even the initial profile download.So the error occurs specifically when a domain joined computer downloads a profile for the first time through WiFi instead of connected to the company network. Again: after profile has been downloaded, Via works fine, also through WiFi.
Yes, disabling auto-login in the profile seems to fix this issue.However, we actually want to use auto-login.Seems like a bug in the client that auto-login prevents an initial profile download on a domain-joined computer connected through a non-domain connection.Issue seems to be it tries to do something on the domain before downloading the profile. But it can't reach the domain (because it's on a non-domain network and VPN has not connected yet) and then it fails downloading the profile entirely.
Hmmmm, should I make a support case for this instead of using this forum?
We use VIA heavily both inside and outside of our domain. We however use a host file entry to resolve for security reasons.
If I understand it correctly (please let me know) you are seeing DNS requests when connecting outside of your Enterprise (dirty internet versus local lan)? But those DNS requests are to a resolver that is unavailable? If this is the case, your request for the profile never happen. They are stopped at DNS?
Not an expert by any means. There are others here that have forgotten more things than I know. Heck, I haven't even figured out how to get via working yet with 8.2. Almost, but haven't. Doesn't the "windows-credentials" command control that? This is my profile. We use Linux only for our connections:
aaa authentication via connection-profile "VIA-YES"server addr "10.10.99.224" internal-ip 10.200.203.6 desc "VIA_OK" position 1no auto-loginauth-profile "VIA-Auth-Profile" position 1no auto-upgradetunnel address 10.200.203.0 netmask 255.255.255.0ikev2-policy "1"ike-policy "Default protection 10001"no windows-credentials <----------------------------- Right hereikev2-protosuiteb-cryptoipsecv2-cryptomap map "GCM256" number 10000client-netmask 255.255.255.0user-idle-timeout 30max-reconnect-attempts 0exit
We have "no windows-credentials" for our profile. I am asking more than advising. We also pre-populate a host file entry so we don't need DNS to work.
Would it be an easy test to turn the windows command off? Do you authenicate off a domain? I do testing inside and outside the enterprise. We have a seperate ISP just for outside the enterprise work which I use for testing this type of thing.
I also have 18 controllers, of which only a few are in production, the rest for testing only.
Wish I could help further. We are heavy VIA users, but use Linux. I posted a lab example of how we handle the profile. We use Certificates to authenicate. Sorry to hear nothing works quite right for you.
The initial profile download requires TCP 443 access from the outside (not just UDP 4500). I would install Wireshark on a lapop with the issue, capture the traffic during the issue and send the pcap off to TAC.
At Aruba, we believe that the most dynamic customer experiences happen at the Edge. Our mission is to deliver innovative solutions that harness data at the Edge to drive powerful business outcomes.
© Copyright 2020 Hewlett Packard Enterprise Development LPAll Rights Reserved.