APM SSLVPN with layered virtual

Forums Technical Forums
, , , ,
1

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

2

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

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.

3

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?

4

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

5

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?

6

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.