6. Bandwidth Throttling IPSEc tunnels demo
The next thing we have to do is look at the QoS traffic QoS policy. We can include the IPsec tunnels. So if we go to QoS we’re going to add a QS profile so that’s the outside interface. And then we’re going to use the default, default for clear text profile for tunnel traffic. We’re going to add the tunnel traffic, tunnel interface. So we’ll have a QS profile for tunnel interface one. A QS profile for tunnel interface two. This way you can control the tunnel traffic QS. So in order for us to do that we need to create a QS profile. So we’re going to add a QS profile site one, this is site three. So start from here. Let’s go to network us profile site one to site two. We’re going to basically give it an Egress that’s given an Egress max of 1024. Well we can just basically limit the max bandwidth to 1024.
So August max is in August max the maximum and megabits. So we’re going to basically give it a max of 1 MB. Okay, so we’re just testing the restriction and then set one to site three. Egressmax is also 1. Then we can apply that QS profile on the interface. Basically apply it on the parent interface which is the untrust interface and it can control the traffic going out on that interface. So create a QS profile. Now we’re going to have to create a QS policy. So interface, so clear text, we’re going to leave it default, we’re not modifying that. And then tunnel traffic, we are going to specify tunnel two QS profile, site one to site two. That limits the traffic to 1. Site one to site three, that limits the traffic to 1 MB. So we saw in QS configuration that we did previously that you can control the traffic based on different type of classes on the clear text. But this basically will show us the QoS based on tunnel traffic so we can go ahead and commit.
And then in order for us to test it out, we’re going to go ahead and set up the Windows machines. So this is one of the Windows machines here. We’ll set it up to go to give it an IP address. Ten 133-525-5250, ten 133, one IP address. So we have all the drives mapped. So now I should be able to see some statistics now that I applied this. US statistics. You see the tunnel one, tunnel two, tunnel three. Statistics. You see here, maximum Egress is one meg. So we’re going to go ahead and try to copy a big file here. Over. Oh, try to copy this. That’s fine. We’ll just to prove it out. So I am on the first machine I’m going to try to copy C program files. Over. Let’s try this copy. So that should generate a lot of traffic since I’m copying, this is the outbound direction. So that has the Egress applied.
I’m going to go to Z and copy. All right, so we see here the traffic bandwidth point 88. 87. So point 93 one. So it’s getting capped at one megabits per second and the default under the tunnel. So we have control over the tunnel because we can classify the traffic. So right now we’re doing an overall classification by limiting the traffic to 1 MB. You see right now is basically controlling the Egress, and we’re going to see how to classify traffic further. So the nice thing about this is to be able to classify traffic and do QS across your IPsec tunnel. So you can have an IPsec tunnel that’s limited to one meg and IPsec tunnel that’s limited to ten meg, and then also you can do further classification based on the applications and the QS level. We’ll see more in the next lecture.
7. IPSec Tunnel QoS traffic classification
So in the previous lecture, we saw classification based on tunnel. The default traffic goes on class four. Like we discussed in previous lecture, we can classify based on application and create a profile for those traffic. Under site one. We can specify the traffic classes and then what type of priority and eagers guarantee they can at. We can create QS policy for the traffic that we’re going to classify. So we can specify here, for example, like file sharing in QoS, let’s put it under class three, trust and then application specify application SMB, MSDS. SMB to validate that this is the session all MSDS SMB. So if you look at one of those sessions, session ID 509, we see that the session QS rule is default, which is class four. So we can change that to class here.
We can give it class two that’s going to go destination is lent to land tunnel. So once I change that, we should see it getting classified differently and we’ll take a look at that. I’m going to start copying file as soon as it finished. Let me open up the statistics. Tunnel two, internal one, internal two. So as you recall in the previous lecture, we see falling under class four the default. So now we’re going to basically copy again and we’ll see that the traffic is going to be under two, basically putting it under different class and classes class two. Now we can make our policy to give a priority based on queuing. We can modify our policy, the policy that we had here, site one to site two. We can specify class two. I’m going to give it high priority and then further give it an Egress max of 50. So I’m giving it an Egress max of 00:50, which is five hundred K. And we can see now it was taken 100 minutes.
So let’s see what the difference is. We can add the same class here, class two, I and Egress max five. So my overall max on that US policy is one meg, but 500K is the max that you’re going to have for SMB traffic and then go back and go to the statistics again. All right, so if we look now, you see it’s class two and it’s getting restricted to obviously we’re going to see it taking more than 50 minutes versus 100 minutes. So typical scenarios like you want to allocate real time for voice. Let’s say this is the one that has voice traffic on it. You give it different class and give it real time as far as queuing.
This way it gets processed, gets in front of the queue much quicker, and then you can have different classes with different Egress max and bandwidth guarantee and runtime bandwidth. So in the case of the Egress max, this is your cap of the traffic. So if I remove the Egress max and make it Egress bandwidth, it will go above 500K, but it will be if the bandwidth is available. So let’s modify that. Let’s see here, we’ll make this set of egress max. Leave that zero and make the egress guarantee . 5 and you will see that it’s going to go above 500K. Go to QS Statistics.
Alright. So we’ll copy it again, paste it again. And now if we look at the traffic, you see it’s going above the 500K. It has a bandwidth allocation. In the case of contention, if there is other classes and other classes are consuming the bandwidth, it will be basically throttled down to 500 kwh. If there is no other applications, the bandwidth can go up above that. So it’s always good to have a bandwidth and maximum guarantee. Having a real time queue for voice and then having high queue for your application, that’s critical. And then having different traffic with different queuing based on the application importance. Right. Voice takes the highest priority. Any other traffic below that will take lowest priorities.
8. IPSec Tunnel QoS controlling traffic bidirectionaly
So in the previous lecture we saw how to apply bandwidth restriction for tunnels. You can apply an Egress max for the tunnel, you can apply Egress max for classes within the tunnel and the Egress max traffic that’s applied is applied to the Egress interface of the tunnel. In the situation where you have side to side tunnel and you control all three sides, or in our case for example, you control all three sides. If you apply the QoS policy you can enforce it bi directionally. So you can enforce from site one to site two, you have one meg. From site two to site one you have one meg and so on. So you have the flexibility if you own all sites in question.
However, if you don’t own the remote site, then your firewall can control the QS traffic outbound and then this control of QS traffic outbound allows you to enforce restriction. What about the return traffic? So if I look at our example here, in the previous example we had a traffic restriction between site one and site two and site one and site three for one bag. But if I go to site three and this is a PC on site three, we’ll see that I don’t have that restriction. So I’m going to paste the file here, and then we’ll see that if I look at the well, in order for me to look at the traffic and statistics, I need to apply a policy profile on the interface, so I need to apply a profile on the trust interface, which is Ethernet one two to see what’s going on. So let’s go here and we will go to Network and US profiles.
We can use the default profile here. US, I’m going to add for ethernet one two and then clear text is going to be default and then commit that so I can see statistics. Then from site three I’m going to paste the folder here and if I look at statistics I’ll find that the traffic from the remote side to me is not bound to my policy because I only applied the QS profile or QRS restriction for outbound traffic. So in order for me to apply the restriction bi directionally, I can do a QS profile on my exit interface which is Ethernet. To enforce that same policy. I’m going to go ahead and cancel and show you how to do that. So here traffic from the site, if they initiate, if I’m connected to site three for example, and they are the one who initiate the traffic, my Egress interface policy is not going to apply.
So I need an egress interface policy for the Trust interface to enforce the traffic coming in from the remote site and apply the same restriction. Thankfully there is a way of doing this based on the source interface. So if I look at the physical interface here, if I go to clear text now it’s clear text this way this time, right? Because here it’s going to be in tunnel traffic from the outbound direction. That’s going to be tunnel traffic when the traffic returns back. And I want to control it on the eager interface, which is my trust interface. This is going to be clear text. So in this case my application will be clear text.
So I’m going to go here and I can apply the same policy. So site one, site three, graphic the QS profile. I’m going to use the same profile that I created, which is site one to site three. And then the source interface dictates that, hey, if traffic is coming in from tunnel three, then I’m going to apply this POS profile and I’m going to do the same for site two. So if it’s coming from tunnel two so now the QoS interface configuration is going to look at the traffic when it exits out the interface, it’s going to look at the source interface and then it’s going to apply that policy that I had configured on my Egress, right? Consequently, it’s going to be using the same policy.
So let’s test it out. So statistics, it was ten meg earlier. So let’s push this out committed and then we’ll see. Now when I try to copy that same folder again, you’ll see that I’m going to get restricted to one meg. At least look at statistics. So now I see hits against side two to side three. However, the class matching is class four. The reason why is here now it’s restricted to one meg, right? At least it’s restricted. The Egress max is one meg. So I can make my POS policy apply to both outbound and inbound. However, because the traffic is not classified, it’s basically falling under class four and the same restrictions not applied that I have on the outbound.
So what I need to do is create a QS policy. And the QS policy, I had a file sharing QS policy from trust to land to land tunnel. MSDS. SMB. I can basically apply it in the opposite direction. In that case it’s going to be from land to land tunnel. So I can add here land to land tunnel to trust and commit that let me cancel the copy. If I go back to statistics, open up statistics and then paste the folder again, I’ll see now that I’m matching the same class and I have the same restriction. So bi directionally. Now I’m applying and enforcing my policy. So that same policy that I had on the eager interface is now applied to the eager interface going to the tunnel. So here I had the policy, site one, site two, okay, that was based on tunnel interface destination, matches tunnel two, applies, matches tunnel two and applies the US profile.
Go in my eager’s direction on ethernet one, one. The untrust, it basically matches tunnel two and applies site one to site two. And on the return traffic, when it exits out the trust interface. It’s basically matching based on tunnel source. So because the traffic is coming in from tunnel two, it’s going to apply the same QS profile and I have my traffic restriction enforced bi directionally classification. Also, I had to create a QS policy. Policy and classification. Also I had to create a clearest policy to apply the same classification when the traffic is initiated from my land to land tunnel to the trust.
9. IPSec QoS Copy ToS Header Explanation and demo
In the previous lecture, we enforce the same policy, egress QS policy on the traffic as the traffic returns by applying QoS profile for the tunnels on the Egress interface. If the session is initiated from site three or site two to site one, when the traffic egress out in the interface, it will get the same restriction, bandwidth restriction and get the same class of traffic when it egress out the Alta firewall thrust interface. So that allows us to guarantee bi directional enforcement of traffic policy from the site out and then from the site in it’s the same policy. Now, the other thing that we want to talk about is changing the POS market or classification on the packet itself.
What we did here, we basically assigned the class that’s internal to the local firewalls just for us to put the firewall in a specific class and give it assigned restriction on bandwidth. Assigned bandwidth priority queuing priority. Whether it’s real time or high or medium or low. We look here, this is the Egress. On the trust side we have traffic is coming in from tunnel three. It gets site one to site three. QS profile. Traffic is coming from tunnel two. It gets site one to site two QS profile if we look at the QS profile. So class two has a queuing of high and Egress max. Egress max. Last thing we did was change it to Egress guarantee of 500K.
So that class is relevant locally on the firewall and it doesn’t get translated to translated to other firewalls you have to configure the same settings on all the firewalls that you have. But what if you want to mark the traffic to give it a different treatment on the network? The marking of the traffic also can be done on the firewall. We saw this previously when we did the regular, the first couple of lectures with the clear text traffic we created in the policy, we set some traffic to a different DSCP value so we can do the same thing here. So for example, let’s say if I want to change the DSCP value for my SMB traffic, change it to a different class so that it gets preferential treatment on the remote sites.
We can do that here. So let me add SMB classification and source is trust, destination is L twelve and then application we’re going to put SMB under other settings. QS marking Ipdscp can give it a value of let’s give it a value of AF 31. So we’re going to give it a tag of AF 31 as it leaves the network. We need to put this up at top the allow all sweet text precedents. And before I commit, let’s see on the machine, let’s see running a wireshark and see what exactly if I look at the SMB traffic, if I look at the IP header, we see the DSCP is zero or CS zero as no marking. Right? So now I’m going to push the configuration and we’ll see that it’s gonna change to have Lakers IP header DSCP is zero. So push this configuration here and we’ll see that the marking of the traffic will change to be AF 31.
So now if I look here so in order for this to take effect, I need to clear the sessions, then let me see if I can see any difference. Now let me open up the Windows machine on site one. I’m just going to do the copy paste again. It should be reestablishing the session because I clear the session. So probably is not happy. So we see here on the remote side we see that now the traffic is marked with AF 31. Here you see the marking AF 31. So the marking takes care of relaying additional information to the network. If you have hops along the path, it can give a different queuing bandwidth requirement. It can also be given importance or given mapping on the remote firewall.
So you can configure the remote firewall if it receives traffic of AF 31, that it puts it on class one, it puts it on class one or class two or whatever class you decide. So that information, when the Palo Alto firewall receives the traffic, sends it to the tunnel, it will basically change the tag or DSCP value to be AF 21 and send it on to the other side. However, when it sends it on, it sends it as an encrypted within the encrypted payload. And if we look at the capture here and we see what type of DSCP value we get on the encrypted payload, on the ESP or the IPsec payload, we will see that the value is not changing. Basically what happens is IPsec takes the packet, encapsulates it in ASP header and sends it out the IP header of this encapsulation CS zero, which is basically nothing, zero value on the DSCP. We don’t see a DSCP that’s 31, AF 31.
And the reason why is there is an additional step you have to do. And it’s important for one reason. If you’re running IPsec tunnel from on the Yen and that IPsec tunnel is running for example an MPLS underlay, that MPLS underlay has provide specific treatment for different type of packets. And let’s say you don’t trust your service provider and you’re going to run IPsec tunnel between your locations over the MPLS network, then somehow you have to relate to that service provider that the packet importance so that they can give it the proper bandwidth allocation and queuing in their network. And if that’s the case, then you have to basically make sure that whatever is configured on the payload gets translated into the IP header of the encapsulated packet.
So how to change that? So basically we can change that. And in Cisco, it’s called QS preclassify. You basically need to go to the Ibisack tunnel and you need to specify and just to make sure let’s do a search here. I’m going to do a search here of DSAP not equal zero. Show you that DSCP. Okay. So we can’t find anything that’s DSP not equal zero. Right? And then now let’s add the feature of copying the Tos to the header. So basically we’re copying the type of service from the payload to the IPsec IP header. As the traffic gets transferred to the remote site under Show advance option, click OK and then commit. Now we see traffic is getting relayed on. So the packet now when it goes out in the IPsec tunnel is tagged with AF 31. You see here, all the traffic that’s going across is tagged with AF 31.
So now I am relaying the importance of the original payload on the IPsec tunnel outer header, the IP header that has the ESP encapsulated within it. And this is important because if you have real time traffic and you’re running IPsec tunnel across your MPLS and you want to make sure that your MPLS provider put your IPsec, your real time queue, in low latency in their backbone, then you have to make sure that it’s marked for EF. And this way it gets the treatment. So it’s pretty powerful what you can do with this, because now you can encrypt your traffic and then basically the information, information about the original packet importance is relayed in your IP headers. So copy to us is another feature that I wanted to make sure you guys understand.
