Forum Discussion
Chris_Brunt_192
Altostratus
AltostratusDTLS VPN doesn't work when SSL profile not default clientssl
I have setup a very basic SSL vpn with APM and I would like to use DTLS to get best performance. The APM policy just checks for AV and authenticates with AD for the time being, I plan to add 2f later.
When I first tested the VPN, I left the default clientssl profile on the VS and just accepted the certificate warnings. It connects fine and I can see in the BigIP client that the protocol in use is DTLS.
If I change the SSL profile so that it uses a certificate issued by our domain PKI or even a proper EV sha256 cert it will only establish a TLS 1.2 and DTLS does not work.
I can't see anything in the log files to say why this isn't working. I know the firewall is correctly configured as DTLS works fine with the self signed certificate.
At the moment I am stuck as the performance of the VPN is nowhere near as good as Cisco AnyConnect over the same link.
Its a 2000s BIG-IP 12.0.0 Build 1.0.628 Hotfix HF1.
Evan_Champion_1Cirrus
BIG-IP 12.0 only supports DTLS 1.0 and so if you are requiring TLS 1.2 then DTLS won't work. Are you requiring TLS 1.2 or ciphers such as ECDHE-RSA-AES256-GCM-SHA384 that are only available with (D)TLS 1.2?
Chris_Brunt_192I have inherited the settings from the clientssl profile. So all the same cyphers should be available. All of the settings are at the default. I will try adding options to say NO TLS 1.2/1.1 and see if that works.
I found some extra logs.
48,2016-02-03,13:33:41:774,HOST,1592,7040,HostCtrl information: property 27, name="tunnel_dtls", value="1". 48,2016-02-03,13:33:41:774,HOST,1592,7040,HostCtrl information: property 28, name="tunnel_port_dtls", value="4433". 0,2016-02-03,13:33:41:821,HOST,1592,7040,The following destination IP address will be used for direct(DTLS) connections: 213.xx.xx.xx 0,2016-02-03,13:33:44:264,,1432,5448,Server supports DTLS 48,2016-02-03,13:33:44:530,,1432,4724,DTLS port is specified, 4433 48,2016-02-03,13:33:44:530,,1432,4724,enter, 0x588: U_ENABLE_HTTP_CHANNEL U_ENABLE_FRAME_PACKETIZER_CHANNEL U_USE_BLOCKING_SOCKET U_ENABLE_DTLS_CHANNEL 48,2016-02-03,13:33:44:530,,1432,4724,enter 48,2016-02-03,13:33:44:546,,1432,4724,exit 48,2016-02-03,13:33:44:546,,1432,4724,OpenSSL version, OpenSSL 1.0.1p 9 Jul 2015 48,2016-02-03,13:33:44:811,,1432,4660,Setting DTLS link MTU (minimum link MTU, new link MTU value), 256, 1280 1,2016-02-03,13:33:45:430,,1432,4660,EXCEPTION caught: UDTLSChannelImpl::Open() - EXCEPTION 1,2016-02-03,13:33:45:430,,1432,4660,EXCEPTION - Name resolution failed, 5 48,2016-02-03,13:33:45:430,,1432,4660,Retry with next IP address 1,2016-02-03,13:33:45:430,,1432,4660,EXCEPTION caught: UDTLSChannelImpl::Open() - EXCEPTION 1,2016-02-03,13:33:45:430,,1432,4660,EXCEPTION - SSL_connect() failed (ssl error, sys error), SSL_ERROR_SYSCALL, 0 48,2016-02-03,13:33:45:430,,1432,4660,channel is not open
- Saravanan_M_K
Employee
Hi Chris, By any chance are you using FEC (Forward Error Correction) profile in your Connectivity Profile? If yes, then try to set it to "None" and see whether the above error goes away. You can access this settings in your connectivity profile --> Edit Connectivity Profile --> General Settings --> FEC Profile. -- Saravanan - Chris_Brunt_192Hi, I checked and in my connectivity profile it says. FEC Profifle (not licenced) so it was already set to None. Thanks.
- Chris_Brunt_192
Disabling TLS 1.1 and 1.2 made no difference. It connects with TLSv1 128 bit, RSA, AES Cipher sha1 HASH etc.
EXCEPTION - Name resolution failed, 5 48,2016-02-03,13:33:45:430,,1432,4660,Retry with next IP addressThis error stikes me as odd. We are connecting with FQDN which is resolvable as the portal page loads.
Further up the logs it has the correct IP address (which i have redacted)
The following destination IP address will be used for direct(DTLS) connections: 213.xx.xx.xx 
lcpWidgitNimbostratus
Hi, did you get it working. I am having the same problem, but I think it maybe something with the ssl cert. We are wanting to use a wildcard cert. As for speed, when the dtls is working ( with an 'invalid' ssl cert ) the speed is about half of what TCP is getting, which is only 10% of the link.
MennoIcpWidgit, I've also noticed with DTLS the speeds are half of that with SSL. You mention this could be due to the wilcard cert? Where you able to fix this issue or have you found more information on this issue?
