Traffic Shaping and prioritizing local VPN Traffic (IPsec, IKE/ESP) on a shared WAN interface?

[topcu]

Hello, we share the bandwith of an ISP uplink on a Fortigate (FWF60E, v6.2.7) to connect a VPN tunnel to a central hub but also to provide local internet access for users and systems connected on the fortigate. I want to control the bandwith of the WAN uplink by applying traffic shaping policies. Limiting and prioritizing the user traffic is not an issue. But is it possible to control also the local tunnel traffic (IKE and ESP) on the uplink?

I my test configuration (s.below) I built a shaper by specifying the tunnel destination IP and the protocols ike and esp (source is dynamic address). But when verifying the diag outputs, it seems, that the shaper is not able to match on local generated traffic. Is this true, and if yes, is there an alternative, to control the tunnel traffic on the shared uplink?

A sample configuration could look like this:

- User realtime internet traffic, min. 5M, max. unlimit, prio High

- Local VPN Traffic (tunnel to central hub), min. 20M, max. unlimit, prio Medium (???)

- User internet traffic, min. 5M, max. unlimit, prio Low

Many thanks in advance! Hakan

[Toshi_Esumi]

It's not a shaper but shaping-policy you can specify source and/or destination to match traffic.

But the addresses you should match with the shaping-policy is supposed to be the real sources and destinations, not the tunnel IP addresses, like local LAN 192.168.1.0/24 and remote LAN 192.168.2.0/24.

Toshi

[topcu]

You are right, we talking about a traffic shaping policy.

Assume the following configuration:
WAN1 (internet uplink) uses DHCP
This interface is the tunnel source
The tunnel destination is 1.2.3.4

Finally I try to catch the ipsec traffic, that is sourced from WAN1 (dhcp) to 1.2.3.4.

E.g. src=192.168.178.20, dst=1.2.3.4, ESP

My shaping policy matches on:
- source = all (because we dont know the dhcp address on WAN1)
- destination = 1.2.3.4 (tunnel destination)
- service = ESP, IKE (IPsec traffic)
- Out. interface = WAN1 (tunnel source)
- shared shaper

But this doesn't work. I assume, that the shaping policy is not able to match on traffic, that is local generated on the fortigate.

Otherwise, as far as I understand what you mean, I had to shape the traffic that is going "through" the tunnel. In this case the source were local LAN, destination remote LAN and outgoing interface the VPN tunnel interface. But this doesn't allow me, to prioritize local user internet traffic over IPsec traffic (or vice versa), that is going shared though WAN1.

[Toshi_Esumi]

The Out/dst interface in the shaping-policy should be the tunnel interface/name, not WAN1, just like firewall policies.

Or if you can share the shaping-policy in CLI, it would be much easier to comment on.

[ADMNET]

Hello,

The problem is the tunnel interface doesn't appaer in the list of outgoing interface. There are only physical interface and vlan, not tunnel.

Any idea ?

[Andreani_Redes]

Hello! Good afternoon, I am having the same problem.
Make shaping policies on WAN interfaces that have IPSec VPN inside. How to do to guarantee traffic.

were you able to fix it?

[Toshi_Esumi]

I'm afraid what OP topcu is describing is the limitation of the traffic shaper. We might not be able to match traffic generated by the FGT itself. Then, if that's the case, only thing we can do is matching other traffic toward the outside of the tunnel via the same wan interface and set the limit in order to leave a room for VPN traffic.

Toshi

[Andreani_Redes]

Good afternoon.
The latter is correct, we cannot capture the traffic captured by the Fw itself, but according to the documentation and from what I verified, all the traffic that passed through the interface and is not associated with a class, it will be implicitly associated with the default class.

With the command, diagnose netlink interface list wan1, you can verify how it is consuming the traffic of the wan interface profile classes.

Check and IPsec VPN traffic falls into the default class. This is easily checked, since if there is only vpn traffic, it matches the current bandwidht in the default class.

In this way, one creates a default class with X % for the Ipsec VPN.

My question is, the wan interface knows how much traffic the interface has and if it is at 100% traffic or not.
But the virtual interface of the ipsec vpn, even if the inbandwidth or outbandwidth is set, how does it know when the interface overlay (wan) is at 100%? Since if I understand correctly, only once the interface is at 100%, it begins to play the guaranteed shaping.

Pablo

[istvanmarlok]

Hi All,

Did You find the right configuration for this issue? Which interface should be the outgoing interface when there is an ipsec over the WAN interface?

Thank you!

Best Regards,

Istvan

[Andreani_Redes]

@istvanmarlok  

Good morning.
We configure it this way:
We create 2 shaping profiles. One for the pure WAN interface and one for the IPSEC VPN.
And what we did was reserve a % of bandwidth, setting it with the in and out bandwidht.

Example: 10 Mbps to internet wan interface.
We reserve 5 Mbps for VPN.
In the wan interface we set the in and out to 10 mbps. And we create the policies in the profile, leaving 50% for "other traffic" and we play with the priorities of the other 50, so that it can be distributed if it is free.

In the vpn-ipsec interface we set 5 mbps in and out bandwithd. And we create the profile assigning 100% of those 5 mbps-

Hope that helps.
Pablo!