Traffic Shaping and prioritizing local VPN Traffic (IPsec, IKE/ESP) on a shared WAN interface?
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
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.
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 22.214.171.124
Finally I try to catch the ipsec traffic, that is sourced from WAN1 (dhcp) to 126.96.36.199.
E.g. src=192.168.178.20, dst=188.8.131.52, ESP
My shaping policy matches on: - source = all (because we dont know the dhcp address on WAN1) - destination = 184.108.40.206 (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.
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.
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.