Jump to content
Welcome to our new Citrix community!

DNS queries over SSL VPN are restricted to A records


Recommended Posts

NetScaler modifies DNS requests that are made over the SSL-VPN so that the request is for A records only.

 

Hence,  DNS queries from VPN clients will never respond to SRV, MX or TXT requests.

 

The command "set DNS parameter resolutionOrder"  talks about this functionality and defaults to OnlyAQuery.

 

Does anyone know why this behaviour is needed and enforced?

Does anyone know how to allow all queries through?

 

Cheers

Link to comment
Share on other sites

Thanks Siddharthas for our quick response.

 

Yes, that was the only article I found and it did not change its behaviour even though the article indicated (in a very cryptic way) that it would send DNS requests and responses directly to the back end DNS server. BTW I must have read the description of the enable vpn_dnstruncate_fix option 50 times and could not make sense of it.

 

What really puzzles me is why restrict all DNS queries to A records only when the request comes over the SSL-VPN? 

 

This must cause other applications to break. Anything that looks up a SRV record, such as AD related tasks. But I cannot see anyone else complaining about it.

 

 

 

Link to comment
Share on other sites

Thanks Siddharthas.

 

NS is 12.0.57.24

Split tunnel is OFF. All traffic must go over the SSL-VPN.

The SSL-VPN is currently using a DNS vServer. Initially I just had a forwarder in place. Under all configurations, DNS resolution for the SSL-VPN works as expected for A records and the DNS cache works as expected.

 

See the following from the reference documentation which does explains that the NS interprets the DNS requests and then does a A record lookup only. So the system is behaving as documented. I don't understand why it works like this and why there is no obvious way to disable it.

 

 

 

resolutionOrder

Type of DNS queries (A, AAAA, or both) to generate during the routine functioning of certain NetScaler features, such as SSL VPN, cache redirection, and the integrated cache. The queries are sent to the external name servers that are configured for the forwarder function. If you specify both query types, you can also specify the order. Available settings function as follows:

  • OnlyAQuery. Send queries for IPv4 address records (A records) only.
  • OnlyAAAAQuery. Send queries for IPv6 address records (AAAA records) instead of queries for IPv4 address records (A records).
  • AThenAAAAQuery. Send a query for an A record, and then send a query for an AAAA record if the query for the A record results in a NODATA response from the name server.
  • AAAAThenAQuery. Send a query for an AAAA record, and then send a query for an A record if the query for the AAAA record results in a NODATA response from the name server.

Possible values: OnlyAQuery, OnlyAAAAQuery, AThenAAAAQuery, AAAAThenAQuery

Link to comment
Share on other sites

I couldn't replicate the problem, with the default resolutionorder setting and without any nsapimgr flag set I am able to get srv record resolved for AD (basically added the client to domain). This is on NS 11.1 latest build.

 

I didn't quite get time to test it out on your build. I will try to get back to you on this. If this is something urgent better open a support case.

 

If possible try running a nstrace and then trigger a dns req for srv record for the domain from a connected client and see where it breaks.

Link to comment
Share on other sites

Thanks Siddharthas,

 

Are you able to perform the test I was doing to keep it simple?

 

nslookup

 

server x.x.x.x

set type=all

_ldap._tcp.dc._msdcs.Domain_Name

 

It did not matter what DNS server x.x.x.x was, providing it was the datacentre side of the SSL VPN  (including when server was the DNS  vServer) the lookup would not work. The same query that that was not traversing the SSL VPN would always work (including when server was the the DNS vServer).

 

"A" record queries would work without problem. (Note IPv6 is off everywhere).

 

I also have an nstrace  and the packets go off to the DNS server, but the query type has magically changed from 'all' to 'A'. I have attached a screen shot of the packet. All looks normal except the query type has been changed. Which is what the documentation says should happen.

 

Cheers,

DNSRequest.png

Link to comment
Share on other sites

Thanks Siddharthas,

 

That's interesting.

 

Other configurations include:

  • AlwaysOn
  • no SPLIT TUNNEL
  • a pre-authentication check on domain membership
  • The plugin is running on Windows 10 release 1803

But everything is working as expected and there were no issues with any of the setup.

Link to comment
Share on other sites

I am able to replicate your problem if I use type=all. The system itself sends query for type=any, type=srv and type=A for _ldap._tcp.dc._msdcs.Domain_Name. and NetScaler is simply forwarding the request(s) as is. 

 

If I set type=srv then the system send query for srv record only and that's what's seen between NS and The DNS server on the back-end. 

 

if it's failing to get the srv record , that's another matter altogether and can only be known after troubleshooting the issue.

 

I would suggest you test with type=srv and then check the packet trace.

Link to comment
Share on other sites

Thanks Siddharthas,

 

Yes the original testing was also performed with the query type as srv (and other DNS tests such as txt). Under all situations the final query packet that reached the DNS server had a query type set to A only. I was just trying to keep the post as simple as possible.

 

Unfortunately, even if certain query types did work, its the application that is making the query and we have no control over it.

 

Do you understand the 'ResolutionOrder' setting mentioned above (and in the eDocs), and why NS wants to modify DNS packets?

Link to comment
Share on other sites

  • 1 year later...

This is an old post, but I'm experiencing the exact same issue.

 

The only difference is that in my case the client is an iOS device. I can see from the apple console log debug that it's trying to lookup the SRV records, but DNS is returning nothing. Packet capture shows that query is for an A record not an SRV.

Logs from Citrix SSO app:

image.thumb.png.a28d10038c78dc5abfeac635208428e0.png
 

Packet capture:
image.thumb.png.e9c52c1018a702bca7e2b47430b440b0.png

 

 

I do see the same behaviour on a Windows 10 machine when using nslookup -type=any. But if using type=srv the lookup is fine.

Anoying since I have no way of influencing how the iOS device sends the DNS query.

 

 

Please, if you ever solved this issue help me out :)

  • Like 1
Link to comment
Share on other sites

1 hour ago, Nils Andreas Myhre said:

This is an old post, but I'm experiencing the exact same issue.

 

The only difference is that in my case the client is an iOS device. I can see from the apple console log debug that it's trying to lookup the SRV records, but DNS is returning nothing. Packet capture shows that query is for an A record not an SRV.

Logs from Citrix SSO app:

image.thumb.png.a28d10038c78dc5abfeac635208428e0.png
 

Packet capture:
image.thumb.png.e9c52c1018a702bca7e2b47430b440b0.png

 

 

I do see the same behaviour on a Windows 10 machine when using nslookup -type=any. But if using type=srv the lookup is fine.

Anoying since I have no way of influencing how the iOS device sends the DNS query.

 

 

Please, if you ever solved this issue help me out :)

 

Yes I sorted it out. From memory it was related to a firmware upgrade screwing up the config of a virtual server that was not being used, later it was enabled and I had the problem. I think I deleted then recreated the virtual server in question and it was recreated clean and working.

 

If that does not help I can check my notes for that project. It was a while ago now.

 

Cheers,
Tony.

 

 

Link to comment
Share on other sites

We noticed this same behavior from iOS devices with Citrix SSO.   Twisting the enable_vpn_dnstruncate_fix knob allowed the SRV DNS queries to actually be SRV instead of As.

 

Adjusting once to test

root@SMELLYSOCKS# nsapimgr -ys enable_vpn_dnstruncate_fix=1
Changing enable_vpn_dnstruncate_fix from 0 to 1 ...  Done.

 

Making the change permanent

root@SMELLYSOCKS# echo "nsapimgr_wr.sh -ys enable_vpn_dnstruncate_fix=1" >> /nsconfig/rc.netscaler

 

If you have a case with support, you can point them to our case of 79282943.

 

Cheers

Chad

 

 

 

 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...