9. IKE security policies required and NAT-T explanation / example
Let’s talk about the security policy that needs to be in place to allow the traffic. Typically what you would have is you have the firewall rules and then you would have at the end you would have deny all any to any. That’s the best practice for security policy because you want to make sure that you allow what you need to allow and then the end you deny all. So what needs to be in place to allow the IPsec traffic to reach the firewall? So typically the firewall connection to the internet is the untrust zone. The name could be different but the untrust zone. So in order for the IPsec VPN traffic to be allowed, you need to create a security rule that allows traffic from untrust to untrust.
You can limit the source. Could be any or if you have specific, if you’re not doing any more access using IPsec and you just have land to land tunnel firewalls connecting to your firewall and you know the IP address source, you can list the sources here and then destination. You can specify the untrust IP address that the firewall receives IPsec traffic on. And then finally you want to restrict to the applications. And the applications that you need to allow are IC, IPsec, ESP and potentially IPsec ESP UDP. The IPsec ESP UDP is used for IPsec connections that are originating behind an ad device. If the source of the traffic is originating behind an ad device or your firewall is behind that device, you need to allow something called net traversal.
Okay, so let’s talk about net traversal here. If you have a net device and you have the firewall source and firewall destination, this net device is translating the source or destination. Net device translates source and destination, source or destination. And that net device is not capable of handling ESP. What happens is let’s say this is the initiator and this is the responder and the initiator would initiate the connection. The IC traffic would pass through reach the responder, the responder would reply and it could change the source port or destination port of UDP connection at the source or destination port. And this could break the IC.
Thomnet devices will not translate to source of destination of IC. But the ESP itself is not able to handle the ESP traffic. So ESP traffic is protocol 50. So since it’s an actual protocol, it is not translatable unless the net device is able to handle the ESP and translate the SPI inbound SPI outbound SPI and has the intelligence to maintain and know what ESP traffic goes where. So in that case, what happens if you have a net device is something is used, is called net translation. And in the case of net translation, the firewalls switch their traffic port from source 500 UDP source destination 500, they change it to port 4500. And once the IC phase one is complete, phase two is complete.
The firewall, the IPsec traffic, the ESP traffic will be encapsulated inside UDP. So the traffic that’s encapsulated inside UDP, in order for you to allow it on the firewall, you have to allow the application IPsec ESP UDP. So that’s the third application that you need to allow. In our example, I introduced an ad device between the two Palo Alto firewall spoke. And this IP address here is two two one. It’s getting translated to there’s an ASA here in the middle.
And that ESA is translating the traffic behind the public IP address of the ESA, which is one, one dot one, one, dot one one. So the source is getting translated to from two two one to one one two. Sorry. Okay. And then also the Pan firewall IP address, which is one one, is getting translated to five five one. So, because this land to land tunnel is set up in aggressive mode, like we saw in the previous lecture, this side has to be set up in dynamic fashion because the shorts of the initiator might not be known. The initiator IP address might not be known, might be a dynamic IP address. And then this side is set up to static. And then the I is set up in aggressive mode.
We’ll see here that the phase one is getting established and phase two is getting established, but traffic is not able to pass through because the firewall, the net device in the middle, is not able to translate the ESP traffic by default, the Pan firewall does not have net t enabled. So we need to enable net t and that will allow the land to land tunnel to switch to EDP port 4500 and encapsulate ESP into UDP. So, let’s see, here our example. I shut down this internet router and I put an ASP in between. And like I mentioned, the traffic from the Spook is getting netted behind the IP address of the outside interface of ASA. And the IP address of the Hub is translated behind five five one. On the Hub site, I will create the security policy to allow the IC traffic.
I call the rule IPsec traffic source is untrust, destination is untrust. And then you can specify destination IP address. It’s optional. You can specify the source too, if you know the IP addresses of all the peers. And then the application you specify IC which allows phase one and phase two negotiation. And then IPsec ASP.And then we’ll leave the IPsec ESP UDP not allowed. So we can see that it’s not going to work without IPsec ASP UDP. And then I’m going to create here because intrazone is allowed by default. intrazone, if traffic is coming in from outside to outside, from untrust to untrust, that’s going to be allowed by default. Best practice is to have deny all at the end of your policy.
And we’ll just any to any this way we are only allowing the traffic that is specified, that is specifically allowed nothing else. You can make this any to any from untrust to entrust. It’s up to you. You can have your rule chat going top down, allowing all the traffic from trust to Untrust from all the zones specifically, exactly like your security policy requires. And then at the end put deny all this way, catch all at the end would deny and you change this to deny. Now the difference between the configuration here because the traffic is going to get netted, the one one is going to get netted to five five one. So on the spoke side, I need to change the IP address, I’m going to change your site, a IP address, I’m going to change to five five one. And I have a packet capture going here and a packet capture going here. Then I’m going to commit the configuration.
I’m going to originate traffic from the spoke site behind the spoke side. Enable ping 1921-6812. And we’ll see here that quick mode is going through, the aggressive mode is going through. So we see here traffic going from one two to one one. This is on the outside, this is the capture here I’m capturing here. The capture here is from two one. Says here the aggressive mode two one to five five one is translated to one one two to one. So here the phase one is going through, phase two is going through. And we see here that we have ESP negotiation. The traffic is not going through because here we see the destination is getting changed, the port is getting changed to 288-2881 to 2888. So the UDP for I phase one is getting changed as well.
So traffic is coming in. If we see here on the spoke side on the hop site, I see informational messages on the spoke site for a tractor paying, you see ESP traffic, right? But that ESP traffic is not showing up on the other side because the net device is not able to handle it, right? So that traffic is basically going nowhere, so it never reaches the hob site. So what do we need to do? Okay, if you look at the quip mode, the aggressive messages, the vendor ID that by default are enabled, there’s dead peer detection and there is no net translation vendor ID that’s negotiated in phase one. So the first step we have to do is negotiate the vendor ID of net translation so that the firewalls know to switch the traffic to port 4500. So we’ll go to the I gateway configuration and we’re going to go to advanced option and enable net translation.
Net traversal, net traversal, not net translation. I apologize. And then commit. And then here I’m going to enable net reversal as well. Okay? And then we’ll go ahead and initiate the traffic. All right. So here we see here nat keep alive. So we see different message. Now this is from behind the net device and let’s go ahead and ping. Getting informational messages. Let me ping again. Show VPN ICSA. Phase one, SA deleted. Notify. Okay. Phase one, change state. Phase one, resent. Phase one. Here it is. So quick mode is getting us negotiated. Let’s see. Phase One show. VPN ICSA. We have an ICSA. Let me clear. This is the ICSA here. So the problem right now is the traffic is not able to traffic for port 4500 is not able to get through here. Source port 4500. Destination port 4500.
The problem is the firewall on the other side does not have IPsec ASP EDP enabled on the policy. So we’re going to go ahead here on the Hub site, we’re going to go ahead and allow IPsec ASP EDP and then commit. And then now let’s go ahead and ping. Okay, there you go. So what’s the difference? I allowed the IPsec ASP UDP application. And now I see the traffic going through encapsulated in UDP port 4500. You see here, this is the UDP Header. And this is the ESP traffic. If you have VPN lent to land tunnel connections, you don’t need to allow IPsec ESP UDP. But if you have VPN clients that are not global protect, you need to allow IPsec ESP UDP. Because in a lot of situations, users at home, when they try to connect, they are behind that device. And if you don’t allow IPsec ESP UDP, it’s not going to work.
10. IKEv1 main mode versus agressive mode, understand the difference
Understand the difference between IQ v one main mode and IV one aggressive mode. In the case of ICV one main mode, one of the requirements is that the IP address of the other side is known in advance and quickly remote. And message one sends the proposal proposal. Message two sends accepted proposal. So this is the initiator and this is the responder name. Message three sends the diffuserman key and then plus the ID that identifies the initiator to the responder. The responder would send its diffuserman key to close the loop on Dflman key exchange. So this was diffusement key exchange. And then message five is the initiator authenticating, providing proof that it is indeed the one that it claims it is by sending a hash.
And this hash would be a hash of its preshared key encrypted and hashed with the shared secret key. That the other side we should have come up with because the responder should know, because I send the responder the ID. So now the responder knows what pre shared key do I have? And if you remember, the preshared key was used to create the cellular random function that creates the keyseat, includes the preshared key. So because the initiator send the responder its ID, now I can look it up and come up with a preshade key. And also it’s going to come up with the hash key, encryption key and face two key. So once it sends its public key back. Now this side, the initiator has all the ammunition to be able to authenticate with authenticate.
Meaning what? As soon as it gets the Diffie Hellman key, it’s going to calculate the shared secret, do the sodarandom function, do the same thing. It’s going to do the same thing here. Hash key, encryption key, phase two key. And then it’s going to send its authentication. The authentication is going to be just putting this information, hash it with the key and encrypt it with the encryption key. And then when the other side gets it, if it can decrypt it using the encryption key and validate the hash by using the hash key, then it checks out, the authentication is complete and this side authenticates back and the authentication is complete.
And then as soon as interesting traffic comes in, quick mode will come up. So one of the key issue here is the identification, right? The identification has to be known in advance. In the case of aggressive mode, this is typically used for devices behind dynamic IP addresses. The ID is not known ahead of time. You have to base your identification based on either group name, the case of a VPN client, or Fcdn or hostname. Okay? So in aggressive mode, the first message from the initiator, because the responder doesn’t know the ID of that initiator, it needs to get this in the first message.
And the first message will have the proposal, the Diffie Hellman key and ID, which is FQDN, hostname or address or group. And then now the responder is able to pick up the authentication information from its own database, whether it’s preshared key or group key or other. And then it’s going to send the response back, authenticating itself because it has to authenticate itself to prove that it has the same key. Right? But before we do that, it’s going to terminate its own diffuserman public key for the responder. It’s going to send the diffihelman key, it’s going to send the authentication digest.
What is the authentication digest is the set runner function of the pre shared key and then produces the hash key, produces the encryption key and phase two key, it’s going to send this information, the authentication hash and it’s going to send this to the initiator. The initiator now has all the information it needs to come up with the same stuff, same function, hash key, the encryption key and it’s going to send its own authentication back. The difference between main mode and aggressive modes is message numbers are six messages instead of three. The requirement of main mode is the IP address has to be known in advance. In aggressive mode that’s not the case.
You can send the group or FQDN or hostname.Let’s see this in action. We’re going to go back to our example that we were working on last time and change this to aggressive mode. To change it to Aggressive mode on the Ipate way, I will specify here to be dynamic and then remote, peer identification would need to be Fkdn, IP address, key ID partner hacks or userfkdn email address. It’s better to use a hostname since that the host might get different IP addresses. So we’ll use the FPD and hostname. We’ll call this site the host. Okay, we did this before but we want to do it now and look at the capture that’s that. And then we have to change the exchange mode to aggressive and then click OK.
And then our gateway and site A, I’m going to change this to dynamic. And then as soon as change the dynamic, the IP address disappeared. And then local identification we do FKD and host name. What did I call it? Site B host make it the same. That’s the local identification. And then we’re going to specify Aggressive and click OK. So because it’s aggressive mode, main hub site here cannot initiate a connection. The connection has to be initiated from the spoke. Like we mentioned a couple of lectures back. So we’re going to go ahead and commit that change. First we have to change this to aggressive. We did that okay. And then we’re going to go ahead and commit here and commit here. Capture the interface, trigger traffic. Now from site B host, I’m going to ping one 8216, one, two. So it’s not coming up.
We’ll do our troubleshooting here. Debug IC global on debug tail follows IC MP log IC from site B and then a ping one more time, we see here dynamic way site A is not allowed. Make sure everything is good here. Oh, on the spoke site it’s going to have to be static, right? Because we know the IP address. So static here did the mistake before one. And then here the mode has to be aggressive. So that’s probably it. And that’s why it’s complaining because you can’t establish a dynamic establish to a dynamic IP address because we don’t know what the IP address is. So one side has to be static, the other side has to be dynamic. So let’s go ahead and ping again and we see here aggressive mode.
The first message have the Security Association exchange type identification and it’s sending its own identification at the first step. And then here you have the authentication data, should have authentication data. Here is the key exchange and this is the authentication data and that closes the loop. But I’m getting a quick mode. I’m getting an informational message. So it’s not happy about the quick mode. Station 500 informational. So the informational message. But because the informational message is after phase one, that means it’s going to be encrypted, so we cannot delete it. So we have to rely on the debug to get there. So let’s do go back to our debug and see what was the message notification message there’s.
Notification message show VPN IPsec SA no ipsecase So it’s failing on phase two. There is an ICSA here and we see that it’s aggressive and the rule is responder. So let’s see debug on the hub site. Try the ping again. Oh, there’s a mismatch. This is group two and this is group one, I believe a mismatch on the PFS, so I need to fix that. That was from our previous lecture. So here we’ll fix the groups and commit. And this is group two. As you can see here the steps are cut down and we see here we’re there’s any issue, you’re going to get informational message back and forth. Right now that I fixed it, we should have full connectivity here. If I do show VPN IPsec SA I see here that traffic is established and the proxy ID is listed.
