Understanding IPSec IKEv1 negotiation on Wireshark
Related Articles: Understanding IPSec IKEv2 negotiation on Wireshark 1. The Big Picture First 6 Identity Protection (Main Mode) messages negotiate security parameters to protect the next 3 messages (Quick Mode) and whatever is negotiated in Phase 2 is used to protect production traffic (ESP or AH, normally ESP for site-site VPN). We call first 6 messages Phase 1 and last 3 messages as Phase 2. Sample pcap:IPSEC-tunnel-capture-1.pcap(for instructions on how to decrypt it just go to website where I got this sample capture:http://ruwanindikaprasanna.blogspot.com/2017/04/ipsec-capture-with-decryption.html) 2. Phase 1 2.1 Policy Negotiation Both peers add a unique SPI just to uniquely identify each side's Security Association (SA): Inframe #1, the Initiator (.70) sends a set of Proposals containing a set of security parameters (Transforms) that Responder (.71) can pick if it matches its local policies: Fair enough, in frame #2 the Responder (.71) picks one of theTransforms: 2.2 DH Key Exchange Then, next 2 Identity Protection packets both peers exchange Diffie-Hellman public key values and nonces (random numbers) which will then allow both peers to agree on a shared secret key: With DH public key value and the nonce both peers will generate a seed key called SKEYID. A further 3 session keys will be generated using this seed key for different purposes: SKEYID_d(d for derivative): not used by Phase 1. It is used as seed key for Phase2 keys, i.e. seed key for production traffic keys in Plain English. SKEYID_a(a for authentication): this key is used to protect message integrity in every subsequent packets as soon as both peers are authenticated (peers will authenticate each other in next 2 packets). Yes, I know, we verify the integrity by using a hash but throwing a key into a hash adds stronger security to hash and it's called HMAC. SKEYID_e(e for encryption): you'll see that the next 2 packets are also encrypted. As selected encryption algorithm for this phase was AES-CBC (128-bits) then we use AES with this key to symmetrically encrypt further data. Nonceis just to protect against replay attacks by adding some randomness to key generation 2.3 Authentication The purpose of this exchange is to confirm each other's identity. If we said we're going to do this using pre-shared keys then verification consists of checking whether both sides has the same pre-shared key. If it is RSA certificate then peers exchange RSA certificates and assuming the CA that signed each side is trusted then verification complete successfully. In our case, this is done via pre-shared keys: In packet #5 the Initiator sends a hash generated using pre-shared key set as key material so that only those who possess pre-master key can do it: The responder performs the same calculation and confirms the hash is correct. Responder also sends a similar packet back to Initiator in frame #6 but I skipped for brevity. Now we're ready for Phase 2. 3. Phase 2 The purpose of this phase is to establish the security parameters that will be used for production traffic (IPSec SA): Now, Initiator sends its proposals to negotiate the security parameters for production traffic as mentioned (the highlighted yellow proposal is just a sample as the rest is collapsed -this is frame #7): Note:Identification payload carries source and destination tunnel IP addresses and if this doesn't match what is configured on both peers then IPSec negotiation will not proceed. Then, in frame #8 we see that Responder picked one of the Proposals: Frame #9 is just an ACK to the picked proposal confirming that Initiator accepted it: I just highlighted the Hash here to reinforce the fact that since both peers were authenticated in Phase 1, all subsequent messages are authenticated and a new hash (HMAC) is generated for each packet.Understanding IPSec IKEv2 negotiation on Wireshark
Related Articles: Understanding IPSec IKEv1 negotiation on Wireshark 1 The Big Picture There are just 4 messages: Summary: IKE_SA_INIT: negotiate security parameters to protect the next 2 messages (IKE_AUTH) Also creates a seed key (known as SKEYSEED) where further keys are produced: SK_e (encryption): computed for each direction (one for outbound and one for inbound) to encrypt IKE_AUTH messages SK_a (authentication): computed for each direction (one for outbound and one for inbound) to hash (using HMAC) IKE_AUTH messages SK_d (derivation): handed to IPSec to generate encryption and optionally authentication keys for production traffic IKE_AUTH: negotiates security parameters to protect production traffic (CHILD_SA) More specifically, the IPSec protocol used (ESP or AH - typically ESP as AH doesn't support encryption),the Encryption algorithm (AES128? AES256?) and Authentication algorithm (HMAC_SHA256? HMAC_SHA384?). 2 IKE_SA_INIT First the Initiator sends aSecurity Association—>Proposal—>Transform,Transform... payloads which contains the required security settings to protectIKE_AUTHphase as well as to generate the seed key (SK_d) for production traffic (child SA): In this case here the Initiator only sent one option for Encryption, Integrity, Pseudo-Random Function (PRF) and Diffie Hellman group so there are only 4 corresponding transforms but there could be more. Responder picked the 4 available security options also confirmed inSecurity Association—>Proposal—>Transform,Transform… payloads as seen above. 3 IKE_AUTH These are immediately applied to next 2IKE_AUTHmessages as seen below: The above payload is Encrypted using SK_e and Integrity-protected using SK_a (these keys are different for each direction). The firstIKE_AUTHmessage negotiates the security parameters for production traffic (child SAs), authenticates each side and informs what is the source/destination IP/Port that is supposed to go through IPSec tunnel: Now, lastIKE_AUTHmessage sent by Responder confirms which security parameters it picked (Security Associationmessage), repeats the sameTraffic Selectormessages (if correctly configured) and sends hash of message using pre-master key (Authenticationmessage) Note that I highlighted 2 Notify messages. TheINITIAL_CONTACTsignals to Initiator that this is the onlyIKE_SAcurrently active between these peers and if there is any otherIKE_SAit should be terminated in favour of this one. TheSET_WINDOW_SIZEis a flow control mechanism introduced in IKEv2 that allows the other side to send as many outstanding requests as the other peer wants within the window size without receiving any message acknowledging the receipt. From now on, if additional CHILD_SAs are needed, a message calledCREATE_CHILD_SAcan be used to establish additional CHILD_SAs It can also be used to rekeyIKE_SAwhereNotificationpayload is sent of typeREKEY_SAfollowed byCREATE_CHILD_SAwith new key information so new SA is established and old one is subsequently deleted.BIG-IP to Azure Dynamic IPsec Tunneling
In one of my previous posts we took a look at configuring the BIG-IP to act as a site-to-site VPN tunnel endpoint for connecting on-premises environments with Azure. At the time the BIG-IP only supported policy-based, (static-route) VPN tunnels. Now, with the latest release of the F5 BIGIP OS, (version 12.x), both dynamic as well as static-based IPSec VPNs are supported. “But Greg, why do I care?”, you may ask. Excellent question! For a good primer on the two version of IPSec VPNs checkout this blog post from Russ Slaten. From a practical standpoint, if your organization needs to connect multiple endpoints, (including Multi-Site, Point-to-Site, and VNet-to-VNet ), to their Azure environment, you must utilize a dynamic route-based VPN configuration. So with that said, let’s take a look at a typical configuration setup. Note: The following steps assume the BIG-IP has been initially configured settings including, but not limited to, licensing, provisioning, and network configurations. Addtionally, an iApp template is available here. The iApp will facilitate the deployment described below. Setup – Configure each of the following objects in BIG-IP as illustrated below. Step 1. Create IPsec Policy – The following IPsec policy created utilizes SHA-1’ for authentication, ‘AES-256’ for encryption, and Diffie-Hellman (MODP1024) Perfect Forward Secrecy. However, you have various options with regards to levels and types of auth/encryption. Refer to the Azure’s page for requirements. Step 2. Create Azure Traffic Selector – During the initial tunnel negotiation, the Azure VPN gateway will advertise ‘0.0.0.0/0’ for both source and destination subnets regardless of the actual on-premises and Azure VNet address spaces. The BIG-IP traffic selector should match this to allow for Azure initiated tunnels. The actual traffic direction, (routing) will be determined by the static route entries, (see Step 6 below). Step 3. Create Azure Peer – The Azure IKE peer utilizes IKE v2, ‘SHA-1’ for authentication, ‘AES-256’ for encryption, Diffie-Hellman (MODP1024) Perfect Forward Secrecy, and a ‘preshared key’. Step 4. Create IPsec tunnel profile and tunnel – This is where dynamic, (aka route-based) IPsec and policy-based IPsec diverge. Utilizing an IPsec tunnel interface allows us to create static routes with the tunnel endpoint as the next hop. This way any traffic destined for the Azure side will be routed through the tunnel. By contrast, policy-based VPNs require a policy that explicitly states which traffic can use the VPN. Step 5. Create Tunnel Endpoint Self-IP and IPsec interface Self-IP. Note:Although required, the address assigned is not utilized by Azure tunnel and the only requirement is the subnet must be unique. Step 6. Create Route – A static route with the newly created tunnel as the next hop allows any traffic hitting the BIG-IP and destined for the specified subnet to be routed through the IPsec tunnel. Step 7. Create a forwarding virtual server – The simple forwarding virtual server listens for and directs traffic over the IPsec tunnel. Additional Links: CodeShare - IPSec Tunnel Endpoint iApp Download Connecting to Windows Azure with the BIG-IP About VPN devices for site-to-site virtual network connections Configuring IPsec between a BIG-IP system and a third-party device Windows Azure Virtual Networks Static vs Dynamic Routing Gateways in Azure – Russ Slaten Blog Post Technorati Tags: F5,BIG-IP,VPN,AES,IPsec,IKE,SHA,AZURE,ADC
Passthrough IPSec with AFM
Introduction When AFM is placed between two IPSec peers, so that it handles the IPSec traffic, we must create specific firewall rules in order to allow IPSec tunnel to be set up and data traffic can be exchanged between clients. The number of firewall rules just as its direction depends on non specifically AFM IPSec configuration. This article explain how these settings can affect to AFM working in passthrough IPSec mode. How to There are two different configuration options that will define how many AFM firewall rules will be needed in our passthrough firewall: DB key ipsec.lookupspi. IPSec ALG profile (ipsecalg). Combinations between these options will make AFM behaves in different ways. Note that there are more IPSec configuration options availables for Big-IP but in this article I only describe those that can affect how AFM firewall handles IPSec traffic when it is sited between two IPSec peers. As a brief summary of both: DB key ipsec.lookupspi defines if we want to take into account SPI in order to forward packet to one or other TMM. In other words depending on the value for this variable Big-IP will use SPI for load balancing traffic among TMMs. This variable will cause flow ports to be 0 instead of using the SPI from the ESP packet, you can confirm this in the log examples below. Also a side-effect of enabling ipsec.lookupspi is that TMM will create two flows per ESP session, one for each direction, this is the reason why this DB key affects to AFM. IPSecALG profile is configured inside the virtual server and it is integrated into AFM and CGNAT so it helps AFM to handle connections. The IPSecALG profile provides network address translation and flow management for Internet Protocol Security (IPSec) and Internet Key Exchange (IKE) flows. I will not describe pros/cons of this ALG in this document, please read specific articles to find out if this ALG really fits into your environment. In this section I will detail with examples how these two options can affect to AFM. It is important to note that we will need as many AFM firewall rules as flows for IPSec are expected to exist in the flow connections table, no flow will be created if packet is not allowed by AFM. Attending to diagram below, when there is not hit in any flow table (HW or SW) packet must be allowed by a firewall rule (and of course by other security filters), if there is a match in a firewall rule that allows the packet then an entry is added to specific flow table. So if Big-IP expects two flows for handling IPSec connections then we need two firewall rules to allow them. *Source: K31591013 In this article I am going to refer only to below firewall rules: velascoOUT_ESP { action accept-decisively ip-protocol esp log yes rule-number 9 destination { addresses { 2.2.2.2/32 { } } } source { addresses { 1.1.1.1/32 { } } } } velascoOUT500 { action accept-decisively ip-protocol udp log yes rule-number 11 destination { addresses { 2.2.2.2/32 { } } ports { isakmp { } } } source { addresses { 1.1.1.1/32 { } } } } velascoIN_ESP { action accept-decisively ip-protocol esp log yes rule-number 10 destination { addresses { 1.1.1.1/32 { } } } source { addresses { 2.2.2.2/32 { } } } } velascoIN500 { action accept-decisively ip-protocol udp log yes rule-number 12 destination { addresses { 1.1.1.1/32 { } } ports { isakmp { } } } source { addresses { 2.2.2.2/32 { } } } } And the following virtual servers: ltm virtual VS-FWD { destination 0.0.0.0:any mask any profiles { fastL4 { } } security-log-profiles { varLogLtm } serverssl-use-sni disabled source 0.0.0.0/0 translate-address disabled translate-port disabled } Note: Logs shown in tests can vary depending on what fields you are configured to log. I only chose the required ones that help to explain this article. ipsec.lookupspi enabled We could say that this DB key breaks firewall stateful inspection ability for ESP. This means that by enabling this DB key (default) two flows are created for ESP traffic, one per direction. Therefore we need to configure three firewall rules in order to allow IPSec tunnel to work as expected (in this example rules velascoOUT_ESP, velascoOUT500 andvelascoIN_ESP). By doing this we will get below flow connections table : Sys::Connections 1.1.1.1:5002.2.2.2:5001.1.1.1:5002.2.2.2:500udp6(tmm: 0)nonenone 2.2.2.2:441.1.1.1:476252.2.2.2:441.1.1.1:47625esp5(tmm: 1)nonenone 1.1.1.1:27622.2.2.2:339011.1.1.1:27622.2.2.2:33901esp5(tmm: 1)nonenone Total records returned: 3 As you can see these flows match with AFM rules configured. If instead enabling the above three commented firewall rules we would only enable firewall rules named 'velascoOUT500' and 'velascoOUT_ESP' then return traffic from remote peer would not be allowed by any firewall rule and this traffic would be dropped, therefore incoming ESP flow would not be created: In this situation by running a ping from internal client to external client we would see how ICMP reply is rejected by default virtual firewall rule: Aug 31 04:23:10 VELASCO info tmm[17718]: 23003137 "VELASCO.afm.passthrough","Global","/Common/global-firewall-rules","1.1.1.1","2.2.2.2","500","500","/Common/INTERNAL","UDP","0","1.1.1.1","2.2.2.2","500","500","/Common/EXTERNAL","UDP","0","Enforced","/Common/GLOBAL-FW-POLICY","velascoOUT500","","Accept decisively","","","","0000565666c4e0a4" Aug 31 04:23:10 VELASCO info tmm[17718]: 23003137 "VELASCO.afm.passthrough","Global","/Common/global-firewall-rules","1.1.1.1","2.2.2.2","3196","14741","/Common/INTERNAL","ESP","0","1.1.1.1","2.2.2.2","3196","14741","/Common/EXTERNAL","ESP","0","Enforced","/Common/GLOBAL-FW-POLICY","velascoOUT_ESP","","Accept decisively","","","","000156576ebc4564" Aug 31 04:23:10 VELASCO info tmm[17718]: 23003137 "VELASCO.afm.passthrough","Virtual Server","/Common/VS-FWD","2.2.2.2","1.1.1.1","3057","3998","/Common/EXTERNAL","ESP","0","","","","","","","","Enforced","","(Default)","","Reject","Policy","","","0000000000000000" And only one ESP flow is created. In this situation IPSec tunnel would be set-up but no return traffic would be allowed: # tmsh sho net ipsec | grep State Tunnel State : up Tunnel State : up Sys::Connections 1.1.1.1:5002.2.2.2:5001.1.1.1:5002.2.2.2:500udp29(tmm: 0)nonenone 1.1.1.1:31962.2.2.2:147411.1.1.1:31962.2.2.2:14741esp0(tmm: 1)nonenone Total records returned: 2 ipsec.lookupspi disabled In this case only one flow is created for ESP what it ease the firewall configuration: Sys::Connections 1.1.1.1:any2.2.2.2:any1.1.1.1:any2.2.2.2:anyesp39(tmm: 0)nonenone 1.1.1.1:5002.2.2.2:5001.1.1.1:5002.2.2.2:500udp26(tmm: 0)nonenone Total records returned: 2 So we only need one AFM firewall rule for ESP and another one for ISAMKP ('velascoOUT500' and 'velascoOUT_ESP'). With these two rules if we repeat the ICMP request we will see only one match in firewall rule since return traffic, ICMP reply, will match ESP flow shown above: Aug 30 08:09:28 VELASCO info tmm[17718]: 23003137 "VELASCO.afm.passthrough","Global","/Common/global-firewall-rules","1.1.1.1","2.2.2.2","500","500","/Common/INTERNAL","UDP","0","1.1.1.1","2.2.2.2","500","500","/Common/EXTERNAL","UDP","0","Enforced","/Common/GLOBAL-FW-POLICY","velascoOUT500","","Accept decisively","00005656596f3a50" Aug 30 08:09:28 VELASCO info tmm[17718]: 23003137 "VELASCO.afm.passthrough","Global","/Common/global-firewall-rules","1.1.1.1","2.2.2.2","0","0","/Common/INTERNAL","ESP","0","1.1.1.1","2.2.2.2","0","0","/Common/EXTERNAL","ESP","0","Enforced","/Common/GLOBAL-FW-POLICY","velascoOUT_ESP","","Accept decisively","00005656596f3a04" Note that for both provided examples only one internal peer can start the IPSec tunnel since we are only allowing ISAKMP in one direction. If we try to initiate the IPSec from the remote peer then traffic will be dropped. But once local peer (1.1.1.1 in this case) establishes the IPSec tunnel clients behind both IPSec peers will be able to send traffic through the tunnel with no issues: Sys::Connections Total records returned: 0 Aug 31 03:40:37 VELASCO info tmm[17718]: 23003137 "VELASCO.afm.passthrough","Virtual Server","/Common/VS-FWD","2.2.2.2","1.1.1.1","500","500","/Common/EXTERNAL","UDP","0","Enforced","(Default)","Reject","Policy","0000000000000000" IPSec ALG attached We can enable IPSec ALG by attaching IPSecALG profile to an Standard virtual server. This is one of the two main restrictions for this ALG and it causes some disadvantages. Since you will not be able to assign this ALG profile to FastL4 virtual servers, you will not be able to accelerate flows using ePVA chip. Also Standard virtual servers make use of LTM pools by default what it could be a problem in some environments. For example, if our requirement is that both IPSec peers must be able to initiate the IPSec tunnel then we will need to create two standard virtual servers each with a pool where the pool member is the remote IPSec. This has another handicap, what if our set of remote IPSec peers are not previously known? In order to avoid this we can force Standard virtual server to route traffic based on destination IP without using a pool by disabling translate-address configuration option, although this could be not possible in some environments (K04116537). Another important restriction for this ALG is that it is designed for accommodating IPsec endpoints that do not support RFC3947 (Negotiation of NAT-Traversal in the IKE). In other words this profile is not designed to handle UDP port 4500 connections. If IPSec peers are going to use NAT-T then you will need to create another virtual server in order to allow this traffic. Please check K97997482 for more information. It is important to take this into account because we could have an environment without NAT-T being used in any IPSec tunnel and suddenly at some point some IPSec traffic start to fail just because one intermediate device starts to NAT connections, and hence IPSec peers change to NAT-T mode. If we forgot ipsecalg limitations troubleshooting could not be trivial. In other words, when playing with this ALG we rely on its possible changes over time (improvements, bugs or limitations). Just as a note aside for IPSec ALG, note that if we delete the IPSec flows from AFM flow table we will see below log in /var/log/ltm, this is expected: Aug 31 05:31:16 VELASCO info tmm[17718]: "IPSEC_TEARDOWN""1.1.1.1:0""1.1.1.1:0""AH""1598875123247""1953384""<null>" Aug 31 05:31:16 VELASCO info tmm[17718]: "IKE_TEARDOWN""1.1.1.1:500""1.1.1.1:500""1598875123247""1953384""<null>" Aug 31 05:31:16 VELASCO info tmm[17718]: "IPSEC_TEARDOWN""1.1.1.1:0""1.1.1.1:0""ESP""1598875123247""1953384""<null>" ALG + ipsec.lookupspi enabled By having this DB key enable we only need one firewall rule allowing ISAMP traffic from the IPSec peer that will initiate the tunnel, ALG profile will handle the rest. This is the configuration which requires less number of firewall rules. For an environment where only firewall rule 'velascoOUT500' is enabled the tunnel will work without problem: Aug 31 04:49:38 VELASCO info tmm[17718]: 23003137 "VELASCO.afm.passthrough","Global","/Common/global-firewall-rules","1.1.1.1","2.2.2.2","500","500","/Common/INTERNAL","UDP","0","1.1.1.1","2.2.2.2","500","500","/Common/EXTERNAL","UDP","0","Enforced","/Common/GLOBAL-FW-POLICY","velascoOUT500","","Accept decisively","","","","0000565668a0f0ef" Sys::Connections 1.1.1.1:any2.2.2.2:any1.1.1.1:any2.2.2.2:500ah8(tmm: 0)nonenone 1.1.1.1:any2.2.2.2:any1.1.1.1:any2.2.2.2:500esp8(tmm: 0)nonenone 1.1.1.1:5002.2.2.2:5001.1.1.1:5002.2.2.2:500udp8(tmm: 0)nonenone 2.2.2.2:23711.1.1.1:86062.2.2.2:2371 1.1.1.1:8606esp8(tmm: 0)nonenone 1.1.1.1:1902.2.2.2:492861.1.1.1:1902.2.2.2:49286esp8(tmm: 0)nonenone Total records returned: 5 Note that due to the way the IPSec profile works under the hoods, the ALG creates by default flows for both possible encapsulation modes, AH and ESP, and not only the one you have configured in your IPSec config. In above case I have configured ESP but AFM creates outgoing flow for both, since only ESP got response only ESP incoming flow is added to the connflow table. ALG + ipsec.lookupspi disabled In this situation ALG is not able by itself of handling all connections, so it behaves similarly as described at ipsec.lookupspidisabled but with worst results. As in the test case without IPSec ALG profile,response traffic will be dropped because ESP return packets are not allowed by any firewall rule, so no flow will be created, but in this case even creating specifically a firewall rule for allowing this traffic will not make it work. IPSec tunnel will be up, but that's all (check K93873214 for more details, article is still valid). This is because IPSec ALG relies on DB key ipsec.lookupspi to work.: Sys::Connections 1.1.1.1:any2.2.2.2:any1.1.1.1:any2.2.2.2:500ah24(tmm: 0)nonenone 1.1.1.1:any2.2.2.2:any1.1.1.1:any2.2.2.2:500esp24(tmm: 0)nonenone 1.1.1.1:5002.2.2.2:5001.1.1.1:5002.2.2.2:500udp24(tmm: 0)nonenone Total records returned: 3 Summary In this section you can check at a glance all the AFM firewall rule requirements attending to the IPSec LTM configuration you want to deploy. ipsec.lookupspi For environments where IPSec ALG profile is NOT used below diagram shows the possible options: IPSec ALG For environments where IPSec ALG profile IS used below diagram shows your choices:
F5 Friday: Why SSL VPN Still Matters
#mobile #vdi #infosec Scale and flexibility make SSL VPN an important part of any corporate remote access strategy You might have noticed a couple of news items from F5 this week that appeared related. If you noticed you were right, they are. First, we were very excited to announce recognition of our hard work on our SSL VPN solutions: F5 Positioned in Leaders Quadrant of SSL VPN Magic Quadrant. Second, we were even more excited to announce adding industry-leading support for Android’s 4.x OS, enhancing its SSL VPN capabilities. Why would be excited about that? Because mobile devices and virtualization (desktop, a la VDI, and server, a la cloud) continue to drive the need for secure remote access at a scale never before experienced by most IT organizations. While web monsters and primarily web-focused organizations have long understand the critical nature of scalability to their business, IT shops for whom a web presence was only somewhat important have not necessarily invested in the infrastructure or architecture necessary to truly scale to meet the increasing demand. It is increasingly the case that IT orgs of all shapes, sizes, and concerns must look to the scalability of its infrastructure to ensure its ability to service users inside and outside the data center via an often times dizzying array of clients and technologies. SSL VPNs arose from similar needs many years ago, out of the overwhelming complexity associated with IPSEC and the inability to support every end-user from every platform available. An SSL VPN generally provides two things: secure remote access via a web-top portal and network-level access via an SSL secured tunnel between the client and the corporate network. By providing both modes of access via an established, ubiquitous protocol (SSL), such solutions are better able to provide end users with access to resources regardless of platform. By deploying such a solution on a proven, highly scalable platform (BIG-IP), such solutions are better able to provide IT with the means to scale not only the solution but its requisite infrastructure services. Enhanced Mobile Support BIG-IP ® Edge Client ™ is the industry’s first SSL VPN solution that provides comprehensive security and mobile access for all devices running Android 4.x (codenamed Ice Cream Sandwich). It’s free, and you can get it anytime you like. Right now, if you want – go ahead. Grab it, I’ll wait. Oh, you aren’t running Ice Cream Sandwich yet? If you’ve got a “rooted” device, we’ve got your back there, too, with our BIG-IP Edge Client for “rooted” devices. Additionally, F5 is introducing enhanced support for its BIG-IP Edge Portal™, which provides managed application access to enterprise web applications such as SharePoint, wikis, and Intranet sites. This is that web top access mentioned earlier – a secure means of providing access to resources from any device without giving away the keys to the kingdom via the more open corporate network access route. And ultimately, this two-pronged approach to secure remote access afforded by SSL VPN solutions like BIG-IP Edge Gateway will continue to be important to corporate remote access strategies precisely because of the need to differentiate levels of service and access based on location, device, and user – something only a context-aware solution can provide. This is why validation of external sources of our work in the SSL VPN arena is exciting – because SSL VPN continues to be a significantly more flexible option to traditional IPSEC VPN connectivity and with the continued growth of mobile devices and demand for technology like VDI, it will certainly only continue to expand its applicability in the enterprise as scale and flexibility become more and more necessary to meet the diverse, distributed demand of clients. F5 Positioned in Leaders Quadrant of SSL VPN Magic Quadrant F5 Keeps Android Users Connected and Productive with New Secure Access Solutions F5 SSL VPN Security Solutions – Overview Magic Quadrant for SSL VPNs – Gartner Report I Scream, You Scream, We all Scream for Ice Cream (Sandwich) Scaling VDI Architectures Strategic Trifecta: Access Management F5 Friday: The Mobile Road is Uphill. Both Ways. All F5 Friday Posts on DevCentral
