Wireless Access

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.

Are you assigning an internal routable subnet to the VIA client ?



Thank you

Victor Fabian

Pardon typos sent from Mobile

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.

I tried disabling auto-login one more time to make sure and that seems to have fixed it. Going to try again to make 100% sure....

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? 

We are seeing domain-related DNS requests being made by the client computer when initially trying to download the connection profile.

This domain-related DNS requests obviously do not function when connected through dirty internet, because domain is unreachable from the internet and VPN has not yet connected. This seems to halt the entire initial profile download.

Once a profile has been downloaded (through a domain-connected connection), everything works fine, also from dirty internet.

So I wonder why the client is trying to do domain-related DNS requests on an initial profile download and I wonder why it's causing the profile download to fail.

We do have a work-around (domain-connected network) that is only required on initial profile download, so it's workable. But still strange.

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 1
no auto-login
auth-profile "VIA-Auth-Profile" position 1
no auto-upgrade
tunnel address 10.200.203.0 netmask 255.255.255.0
ikev2-policy "1"
ike-policy "Default protection 10001"
no windows-credentials <----------------------------- Right here
ikev2-proto
suiteb-crypto
ipsecv2-cryptomap map "GCM256" number 10000
client-netmask 255.255.255.0
user-idle-timeout 30
max-reconnect-attempts 0
exit

 

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.

Maybe, I haven't tested with auto-logon enabled and windows credentials disabled.

But once initial profile is downloaded, all later connections and profile downloads work fine, even with auto-logon and windows credentials enabled. So something 'special' is happening during the initial profile download.

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.   

Yes, we authenticate with domain credentials.

Just tested it with auto-logon enabled and windows credentials disabled: also results in profile download error. So, it really seems to depend on auto-logon being enabled or not.

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. 

it works with auto-login disabled.

it also works when connected to the internal network during initial profile download.

after initial profile download, it works everywhere.

so, we're able to deal with it. It's only an issue when a user is not in the office, does not have the initial profile download yet, and needs access to the internal network. We're unable to setup via in that case. Work-around is for them to come to the office to do the initial profile download.

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.

Jup, got 2 wireshark captures. 1 on public internet, 1 on local domain network. However, I'm in some migration process for Aruba Support and it isn't going very fast... So can't open TAC yet it seems.

PS: 443 is open. I'm able to do web authentication and download the MSI installer from the controller.

Apparently, we do not have the right kind of support contract on the controller? I think they won't look at my captures now. Too bad.