ITC/3AV WIKI

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
**Is it possible to route Google meet video call traffic on one channel and the rest of the traffic on the other channel?**


Option A:

**With PBR to meet addresses: IPv4: 74.125.250.0/24**

**IPv6: 2001: 4860: 4864: 5 :: 0/64**

A simple static routing entry specifies how to handle traffic that matches specific criteria, such as destination address, destination mask, gateway to forward traffic, the interface that gateway is located, and the route metric. This method of static routing satisfies most static requirements, but is limited to forwarding based only on destination addressing. SonicWall firewall (UTM) appliances running SonicOS Standard and Firmware 6.x support static routing.

Policy Based Routing (PBR) allows you to create extended static routes to provide more flexible and granular traffic handling capabilities. SonicOS Enhanced PBR allows for matching based upon source address, source netmask, destination address, destination netmask, service, interface and metric. This method of routing allows for full control of forwarding based upon a large number of user defined variables. A metric is a weighted cost assigned to static and dynamic routes. Metrics have a value between 0 and 255. Lower metrics are considered better and take precedence over higher costs. SonicOS Enhanced adheres to Cisco defined metric values for directly connected interfaces, statically encoded routes, and all dynamic IP routing protocols. Although PBR permits traffic routing based on ports and protocols, it does not perform any network and/or port translation. PBR is configured on the Network > Routing page of the web management interface on a SonicWall firewall (UTM) appliance running SonicOS Enhanced firmware.

Although PBR may seem similar to port forwarding, there are significant differences. Port forwarding allows you to create access to multiple internal servers via the same Public IP address. For example, you can allow for access to a Webserver and an FTP server via the same Public IP address even if they are two separate servers. Since the SonicWall supports inbound port forwarding, it is possible to hide internal servers off the WAN IP address. Although the packet coming from the client is destined for the WAN IP Address of the SonicWall, the SonicWall distinguishes whether to send it to the Webserver or FTP server (in our example) based on the Port. If the packet is destined for Port 80, the SonicWall will forward it to the Webserver. If it is destined for Port 21, the Sonicwall will forward it to the FTP server. This forwarding does not perform any routing between differing subnets. The internal and external IP address subnets must be directly assigned to interfaces on the SonicWall appliance or routes for them must already exist by way of implementing Policy Based Routing or use of a dynamic routing protocol. Port forwarding capability is configured on the Network > NAT Policies page of the web management interface on a SonicWall firewall (UTM) appliance running SonicOS Enhanced firmware.

Option B:

You can also do a PBR per application, indicating that the app object is google meet but it would be necessary to apply DPI-SSL and apply the SonicWall certificate to the users.

{{:sonicwall:pbr_app.jpeg?600|}}