Technical Forum
Ask questions. Discover Answers.
cancel
Showing results for 
Search instead for 
Did you mean: 

APM SSLVPN with layered virtual

svs
Altostratus
Altostratus

Hi guys,

 

I'm trying a new (for me), but oftenly recommended by F5 SEs, setup with layered virtuals. In my testing environment, I have only one single IP address. This is used for a standard virtual server, which will be used as some kind of a jump VS (let's call it 'VS_jump'). I've assigned an LTM policy to this VS, which forwards the traffic to different virtuals, based on the requested host header.

 

Basically this is working finde. But I'm struggling arround with APM and SSLVPN (Network Access). The requests hit the correct VS ('VS_apm-sslvpn') with APM profile assigned and the user is able to authenticate. But after opening the PPP tunnel, it's ending in a timeout for the client. The APM log tells me, that the tunnel was directly closed:

 

PPP tunnel 0x56009ef6dd00 (ID: 703c0a5b) started. PPP tunnel 0x56009ef6dd00 (ID: 703c0a5b) closed.

This issue only occurs, if the APM profile is bound to the forwarded virtual, 'VS_apm-sslvpn'. For testing purposes I've assigned the APM and connectivity profile to 'VS_jump' and the connection came up directly, without any issue. The message

 

PPP tunnel 0x56009ef6dd00 (ID: 703c0a5b) closed.

only appears, when the connection is manually disabled.

 

So my question is: Are there any known limitations to SSLVPN, when used in conjunction with layered virtuals? I'm not sure about settings like HTTP-XFF or SNAT - where shall they be set? On 'VS_jump' or 'VS_apm-sslvpn'.

 

Unfortunately I wasn't able to find anything related to SSLVPN and layered virtuals.

 

Any ideas?

 

Thanks in advance.

 

Cheers,

 

Sven

 

5 REPLIES 5

Stanislas_Piro2
Cumulonimbus
Cumulonimbus

The best solution is to create a layered policy based on Client Hello SNI value instead of HTTP Host header..

 

https://devcentral.f5.com/articles/sni-routing-with-big-ip-31348?tag=SNI

 

This solution allow to route based on SNI (default value from browser is the same value as HTTP host). this doesn't require to add SSL / HTTP profiles on front virtual server.

 

Another improvement is to enable DTLS virtual server (udp/4433) to optimize VPN performance. This virtual server doesn't require to be layered as it is only for VPN.

 

I'm using SNI routing configured almost exactly like the article, matching at client ssl hello and forwarding to an APM SSLVPN enabled VS.

 

Same symptoms as OP.

 

Is there some other magic to making this work, or is it not supported?

 

Sven, did you ever happen to get this to work?

Hi,

 

yes I got this working. Can't remember, why I didn't respond to Stanislas answer.

 

My LTM Policy looks like the following:

ltm policy SNI-Routing { controls { forwarding } requires { client-ssl } rules { Default { actions { 0 { log ssl-client-hello write facility local0 message "Nothing mathed on hostname" priority info } } ordinal 1 } vpn.example.com { actions { 0 { forward ssl-client-hello select virtual /Common/vpn.example.me_ap_vs } } conditions { 0 { ssl-extension ssl-client-hello server-name values { vpn.example.com } } } } } status published strategy first-match }

VS

ltm virtual vpn.example.me_ap_vs { destination 1.1.1.10:443 ip-protocol tcp mask 255.255.255.255 profiles { http { } ppp { } rba { } tcp { } vpn.example.me_ap { } vpn.example.me_ap_cp { context clientside } vpn.example.com { context clientside } websso { } } source 0.0.0.0/0 translate-address enabled translate-port enabled }

VS DTLS

ltm virtual vpn.example.me_ap_vs_dtls { destination <External Self IP>:4433 ip-protocol udp mask 255.255.255.255 profiles { ppp { } udp { } vpn.example.me_ap_cp { context clientside } vpn.example.com { context clientside } } source 0.0.0.0/0 translate-address enabled translate-port enabled }

The DTLS VS is not going through the LTM SNI Routing policy. Instead it is, in my case, bound directly to the external Self IP, with only SSL client profile and connectivity assigned.

 

APM Profile

apm profile access vpn.example.me_ap { accept-languages { en } access-policy vpn.example.me_ap app-service none customization-group vpn.example.me_ap_logout default-language en eps-group vpn.example.me_ap_eps errormap-group vpn.example.me_ap_errormap framework-installation-group vpn.example.me_ap_framework_installation general-ui-group vpn.example.me_ap_general_ui generation 1 generation-action noop log-settings { default-log-setting } modified-since-last-policy-sync true type all user-identity-method http }

Connectivity Profile:

apm profile connectivity vpn.example.me_ap_cp { adaptive-compression enabled app-service none client-policy { vpn.example.me_ap_cp { ios-ec { save-password true } ios-ep { save-password true } } } compress-buffer-size 4096 compress-cpu-saver true compress-cpu-saver-high 90 compress-cpu-saver-low 75 compress-gzip-level 6 compress-gzip-memlevel 8192 compress-gzip-window-size 16384 compress-ingress false compression enabled compression-codecs { deflate lzo bzip2 } customization-group vpn.example.me_ap_cp_secure_access_client_customization defaults-from connectivity deflate-compression-level 1 description none fec-name none location-specific false tunnel-name vpn.example.me_ap_cp }

Hopefully this help.

 

 

Cheers

Sven

 

Thanks. So the SNI-Routing policy is applied to another VS which is bound to the external self IP as well? (the jump-vs equivalent in your original post)?

 

I'm missing the DTLS portion, but it isn't enabled, so should fall back to TLS/443, but still fails just as your original post describes.

 

Version 13.2 I think, how about you?

My "jump-vs" is the SNI-Router VS, or in other words the "outer VS". So there is the SNI-Routing LTM policy applied. This VS is only used for service ports, which are used for SSL/TLS connections - otherwise SNI wouldn't work. I didn't check if DTLS does support SNI and therefore didn't use the "jump-vs". So my DTLS VS is just another Standard VS, without any LTM policies applied. On the other hand, the SNI-Routing LTM policy doesn't support the combination of SNI and TCP port conditions (at least not in my environments, tested with 13.1.x, 14.x and 15.0). For me this resulted in TCP resets on the outer VS.

 

This special environment has only a single private IP address, forwarded from a NAT router in front of the BIG-IP, which has a single public IP address.

 

My setup is on 15.0.x and will be updated to 15.1.x within the next days.