Asymmetric routing for dedicated management interface

[KonsSyll]

Hello all,

We are in the process of migrating management traffic for our on-premise Web Gateways to a dedicated VLAN/physical interface.

This is only for the GUI and SSH into the boxes, everything else can be routed based on the routing table.

So we have decided on a setup similar to the one below:

eth0 - external interface, default gateway of the box

eth1- internal interface, static routes to all internal networks are in the routing table already

eth3 - management interface on a separate VLAN.

What I suspect is that the above will result in asymmetric routing since the return traffic of the management sessions, will follow the static routes in the routing table that point to the internal interface.

Is there any way to solve this in a "VRF" way on the appliances specific to the management traffic/interface?

Updating the existing static routes or having dedicating management hosts on the new VLAN is not an option so I am trying to solve this on the appliance instead of configuring NAT on the management VLAN gateway.

Thank you,

Konstantinos

[fw_mon · Accepted solution]

Hello @KonsSyll 

you have two options:

1. Configure Source-based routing for the management interface as described here success.myshn.net/Skyhigh_Secure_Web_Gateway_(On_Prem)/Secure_Web_Gateway_Appliance_System/Source-based_Routing

2. Since version 12.1 there is a "Return To Sender" options. The Return-to-Sender (RTS) option eliminates the need to create static routes by configuring the appliance to send response packets back to the same interface that received the request packet, entirely bypassing any routing lookup on the appliance. Essentially, the appliance stores the source Ethernet MAC address that the client’s packet came from and sends all responses to that address. The RTS interface mapping is updated each time a packet is received. For example, if there are two gateways and both of them send packets to the appliance, the packets are sent back to the last MAC address and interface that received the packet.

[KonsSyll]

@fw_monI really appreciate the response.

Option #1 appears to be what I am looking for as we are on version 11.2.x currently with no plans to change main version.

Just a question on this article, if I may. On step "g" in the destination field the subnet can be something that already exists in the actual routing table of the appliance however the alternate routing table will be used based on the routing table number so no traffic reaching the "internal" interface will be affected, is that correct?

[fw_mon]

@KonsSyll that's correct. The SBR will take precedence.

A couple of Best Practices:

• if you have hardware appliances - make sure you have RMM access, it is very likely you'll lost access to the appliances if you enter wrong SBR configuration. This process takes usually a couple of try-and-error attempts until it works.
• don't forget about other mgmt traffic
• if you have a central management cluster - start with an appliance where you aren't logged on - in this case you'll avoid logout/login cycle.
• And I would always suggest don't do it in your prod environment, but try it in a test environment first!