SNAT irule doesn't match for a FastL4 VS for an IPSEC VPN
Hi everybody, I have a problem to bring up an IPSEC Tunnel between 2 firewall with one of them behind an F5 BIGIP. What I did : Create a VS FastL4 (Source Address 0.0.0.0/0, Destination Address my_public_ip_used_for_the_vpn, Service port All_Ports, Protocol All, Source Address Translation NONE). For the SNAT I tried to use a SNAT POOL For the SNAT I tried to use an iRule : when CLIENT_ACCEPTED { if { [IP::addr [IP::client_addr] equals 10.199.0.1/32] } { snat X.X.X.X.85 nexthop X.X.X.X.1 log local0. " -- SNAT VPN IPSEC S2S -- [clientside {IP::remote_addr}]:[clientside {TCP::remote_port}] to [clientside {IP::local_addr}]:[clientside {TCP::local_port}]" } } For the SNAT I tried to use GUI : In all case the F5 doesn't take my SNAT rule and the traffic take another public IP. On the peer device (which is not behind an F5) I have a log "Asymmetric Routing". It's normal because he tries to establish the tunnel with an IP and there is another IP that respond to him. On the F5 I can see it on the logs 16:30:36.409542 IP Y.Y.Y.Y.isakmp > X.X.X**.85**.isakmp: isakmp: phase 1 I ident 16:30:51.939720 IP 10.199.0.1.isakmp > Y.Y.Y.Y.isakmp: isakmp: phase 1 I ident 16:30:51.939732 IP X.X.X**.251**.20251 > Y.Y.Y.Y.isakmp: isakmp: phase 1 ? ident The peer device seems to successfully contact my firewall on Y.Y.Y.85 but the F5 respond with the Y.Y.Y.251 Is there anything that I forgot in the configuration?
Explicit Forward Web Proxy, forward proxied traffic over IPSEC terminated on F5 to remote device.
I have succesfully set up an IPsec tunnel between the F5 and remote device. I have HTTPS server configured on the remote end and on a client I able to connect to the HTTPS server when using the F5 internal interface as the default gateway on the client. I have succesfully set up the explicit forward proxy and when I configure the client to point to the virtual server I am able to proxy web traffic out to the Internet. (Bypassing the IPsec tunnel and going to the Internet) However I am not able to force the proxied traffic over the IPSEC tunnel succesfully to reach my HTTPS server on the remote end.
F5 Not Functioning With Pulse Secure
Hi All, We have a new set-up of an F5 with two VIPS - one performance layer 4 for https (SSL authentication to the pulse secure appliance), ad another standard VIP on UDP/4500 (for IPSec data traffic). Both Profiles have a source affinity persistence profile mapped to them which has option "Match Across Virtual Server" checked. This is to allow Both VIPS to act as one for Data Traffic. The F5 has also two Gateways configured as self IP's and their respective floating IP's - this is so the pulse uses the F5 as its gateway for internal and external traffic. The routing on the F5 points internal traffic to a default route to a switch in the DMZ which knows the route to the data center - and was being used to route traffic in the old set-up too. What we found with the new set-up was that traffic going to the external port worked fine, but traffic to the internal port on the pulse (routed via the F5 internal gateway) was not working at all. This interface should use its own IP address and initiate a request to Authentication servers, but did look like it was - resulting in users not being able to log into their pule clients (as authentication was failing). In the old set-up the gateways were on two separate switches, and this worked even after we reverted back - we saw users able to connect and log into pulse - where as in the new set-up they couldn't go past the prompt. We believe the issue is only with internal traffic, as external traffic looks fine. We also believe it could be the F5 potentially stopping the traffic from passing but not sure why. Could the profile be changing something in the packet header? Could both VIPs also need to be standard VIPS for this to work ? Has anyone come across an issue like this before ? Best Regards, Sabeel
IPSec VPN - Must the tunnel local address be the self/floating IP address?
Hello everyone, Regrading IPSec VPN (tunnel mode) setup, I have no idea whether the tunnel local address can be different than the self/floating IP address (another IP address in the same range with self/floating IP address) or not, but I noticed this when I was working on a F5 BIG-IP system. For example, the self and floating IP addresses are a.b.c.200/25 and a.b.c.202/25, respectively, but the tunnel local address is a.b.c.199/25. However, when I checked the system configuration, I could not find the IP a.b.c.199/25 assigned or associated to any interfaces/VLANs, but only ltm nat-translation, snatpool (for IPSec local encryption domain - private network) and a few rules for ESP/IKE packets. Additionally, I could ping this IP address from the BIG-IP system.
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:
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,ADCUnderstanding 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.
