ipsec
33 TopicsUnderstanding 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.23KViews1like0CommentsUnderstanding 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.23KViews3likes0CommentsBIG-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,ADC5.1KViews0likes9CommentsDuring ike rekey in a s2s IPsec config some tunnels won't reestablish
Hi, I would like some help regarding an IPsec problem we are experiencing in our DC. We have a few different route domains in our F5. Two different RDs are configured for IPSec to two different remote sites. The only thing common between the two connections is that both remote device is a Cisco ASA. One is an ASA5520 on 7.2(4) and the other one is an ASA5585 on 9.2(4)14. Here are the details of the IPsec configuration: PHASE1 Version:IKE v1 Authentication algorithm:SHA-1 Encryption algorithm:AES256 Perfect forward secrecy/dh-group:MODP1536 Lifetime:1440 Authentication method:PSK Mode:Main NAT Traversal:ON DPD Delay:30 sec Replay window size:64 packets PHASE2 IPsec protocol:ESP Mode:Tunnel Authentication algorithm:SHA-1 Encryption algorithm:AES256 Perfect forward secrecy:MODP1536 Lifetime:1440 It has been verified by both sides multiple times that the configuration is exactly the same. Also, we are the ones using NAT-T. We have an external router where the public ip address is NATed to the F5. The problem is that during ike rekeying some tunnels won't reestablish. Only some will, but not all. For example in one ipsec there are 3 traffic selectors. Traffic is flowing through in all 3 of them when everything is fine. After the rekeying only one will work and we have to clear the whole ipsec to make it work again. What we found so far that the ASAs will start rekeying at 75% of the lifetime (so in our case around 18 hours) https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/81824-common-ipsec-trouble.htmlvpndisc According this document it's not a problem. However, almost always the tunnels won't come up. (There have been a few occasions when for some magical reason they came up but it's pretty rare..) Log from the ASA when rekeying starts at 18 hours. Mar 7 02:50:51 asa %ASA-4-113019: Group = 1.2.3.4, Username = 1.2.3.4, IP = 1.2.3.4, Session disconnected. Session Type: IPSecLAN2LANOverNatT, Duration: 18h:00m:29s, Bytes xmt: 4133553397, Bytes rcv: 2396963220, Reason: IKE Delete Here are the logs from the racoonctl log, as it is too long to paste it here: https://pastebin.com/H39ZbYLS So the conclusion so far is that there is traffic between the peer IPs, even when the problem occurs. The traffic in the IPsec SAs goes back and forth continuously. When the IKE rekey happens the old IKE SA closes and a new one is created and the IPsec SAs are renewed. For a second the traffic in the IPsec SAs breaks but then continues to flow once again. But when the error happens not every IPsec SA reestablishes and we can only see timeouts in the logs. I hope you can help. The clients are a "bit" mad about this issue. Thanks.Solved2.8KViews0likes1CommentDoes anyone have 11.6 LTM doing IPsec with 3rd party device
We are trying to create ipSec tunnel with 3 traffic selectors on one IKE peer. The tunnel will come up, however we aren't able to get any traffic flowing over the link. Traceroute shows that the connection is trying to go over the default route, rather than into the tunnel. F5 shows that the tunnel is active and receiving packets - just not sending any. We are using a secondary floating self-ip on the external network. 10.0.0.0/8 route to internal network. Remote network is 10.0.5.0/24.Solved1.1KViews0likes19CommentsF5 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, Sabeel1KViews0likes1CommentConfigure F5 for IPsec VPN as pass through
Hello, We wish to implement the IPsec VPN via F5. The traffic flow as, Client(windows mobile) --> Internet --> Firewall --> LTM(one armed mode, SNAT) --> Microsoft TMG. When we try to configure as standard virtual server(on port UDP 500 & 4500), source IP based stickiness & with SNAT, the client are able to establish tunnel and access their application. But frequently, they are getting error message as "VPN server is unavailable" If the client establish IPSec tunnel directly to TMG, we are seeing the communication is happening with ESP(UDP 50) and they are not getting error? Kindly let me know the standard configuration for IPSec VPN pass through configuration also IPSec VPN with standard virtual server won't work or ? Thanks in advance. Regards, Kannan.920Views0likes4CommentsIPSec 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.810Views0likes1CommentEstablish IPSec VPN with F5 Big-IP and Fortigate 30C
Our primary requirement is to establish IPSec VPN with our F5 Big-IP 5050 on our DataCenter to Fortigate 30C on our branches across the globe. Question 1. We haven't successfully done the configuration with both using Static IP. What is the right configuration? 2. Is F5 capable on establishing IPSec VPN to Fortigate 30C's via Dynamic IP? 3. Is F5 capable on establishing IPSec VPN to Fortigate 30C's via Dynamic DNS? 4. What are other method we can establish VPN from F5 to Fortigate 30C? Help.799Views0likes2Comments