Technical Tip: VoIP (Specific) traffic to use only 1 WAN connection in SD-WAN

rahulkaushik-22 · ‎08-24-2023

Description

This article discusses VoIP(Specific) traffic to use only 1 wan connection in SD-WAN.

Scope

FortiGate.

Solution

Topology:

Currently, there is no feature that can exempt specific networks not to using the implicit SD-WAN rule. So, it is possible to achieve it with the help of a firewall policy where each ISP belongs to an individual SD-WAN zone.

There are 2 SD-WAN zones: VoIP and DATA.

Wan1 belongs to the DATA zone and Wan2 belongs to the VoIP zone.

Create a static default route with both zones:

It is necessary to create two firewall policies.

The first policy will allow VoIP traffic to use Wan2 only and hit the implicit deny rule when Wan2 is down because the outgoing interface only has a VoIP zone.
The Second policy will allow Data traffic to use both wan interfaces as the outgoing interface has both zones. It will prefer the Wan1 interface due to the SD-WAN zone as long as it's up.

SD-WAN rules allow the Data to use the Wan1 interface and VoIP to use the Wan2 interface:

Testing:

A PC from the voice network(10.10.10.0/24) ping 1.1.1.1 when Wan2 is up. It is successful as Wan2 (port2) is up.

Challenger-kvm24 # dia sniffer packet any ' host 1.1.1.1 and icmp' 4 20
Using Original Sniffing Mode
interfaces=[any]
filters=[ host 1.1.1.1 and icmp]
4.042439 port3 in 10.10.10.2 -> 1.1.1.1: icmp: echo request
4.042477 port2 out 10.9.32.13 -> 1.1.1.1: icmp: echo request
4.048990 port2 in 1.1.1.1 -> 10.9.32.13: icmp: echo reply
4.048998 port3 out 1.1.1.1 -> 10.10.10.2: icmp: echo reply

Wan2 goes down, so the voice network should not be able to send access Internet (1.1.1.1) as it is the therequirement. The ping failed on the PC due to an implicit deny policy.

C:\>ping 1.1.1.1

Pinging 1.1.1.1 with 32 bytes of data:
Request timed out.
Request timed out.

Diag de flow on FortiGate shows traffic is denied by implicit policy.

hallenger-kvm24 # id=65308 trace_id=11 func=print_pkt_detail line=5861 msg="vd-root:0 received a packet(proto=1, 10.10.10.2:1->1.1.1.1:2048) tun_id=0.0.0.0 from port3. type=8, code=0, id=1, seq=19."
id=65308 trace_id=11 func=init_ip_session_common line=6047 msg="allocate a new session-00004078, tun_id=0.0.0.0"
id=65308 trace_id=11 func=__vf_ip_route_input_rcu line=1994 msg="find a route: flag=00000000 gw-10.9.15.254 via port1" <-- Wan1
id=65308 trace_id=11 func=__iprope_tree_check line=524 msg="gnum-100004, use int hash, slot=43, len=1"
id=65308 trace_id=11 func=fw_forward_handler line=839 msg="Denied by forward policy check (policy 0)"

Now, let's test from Data network(10.10.20.0/24). Both Wan interfaces are up.

Traffic went over port1 (Wan1) as expected.

Challenger-kvm24 # dia sniffer packet any ' host 1.1.1.1 and icmp' 4 20
Using Original Sniffing Mode
interfaces=[any]
filters=[ host 1.1.1.1 and icmp]
2.527153 port10 in 10.10.20.2 -> 1.1.1.1: icmp: echo request
2.527183 port1 out 10.9.11.8 -> 1.1.1.1: icmp: echo request <----- Wan1 .
2.533522 port1 in 1.1.1.1 -> 10.9.11.8: icmp: echo reply
2.533527 port10 out 1.1.1.1 -> 10.10.20.2: icmp: echo reply

Wan1 goes down, and Wan2 is up, and now, Data network traffic will go over wan2 as expected.

Challenger-kvm24 # dia sniffer packet any ' host 1.1.1.1' 4 20
Using Original Sniffing Mode
interfaces=[any]
filters=[ host 1.1.1.1]
5.057100 port10 in 10.10.20.2 -> 1.1.1.1: icmp: echo request
5.057143 port2 out 10.9.32.13 -> 1.1.1.1: icmp: echo request <----- Wan2.
5.063614 port2 in 1.1.1.1 -> 10.9.32.13: icmp: echo reply
5.063623 port10 out 1.1.1.1 -> 10.10.20.2: icmp: echo reply

So, with the help of the SD-WAN zone and firewall policy, it is possible to achieve it.