cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
KonsSyll
Level 8
Report Inappropriate Content
Message 1 of 4

Asymmetric routing for dedicated management interface

Jump to solution

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

1 Solution

Accepted Solutions
fw_mon
Reliable Contributor
Reliable Contributor
Report Inappropriate Content
Message 2 of 4

Re: Asymmetric routing for dedicated management interface

Jump to 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.

 

 

Was my response useful to you? If so, please consider marking it as an Accepted Solution and/or giving it a Kudo to help other community members.

MWG+Splunk=❤

View solution in original post

3 Replies
fw_mon
Reliable Contributor
Reliable Contributor
Report Inappropriate Content
Message 2 of 4

Re: Asymmetric routing for dedicated management interface

Jump to 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.

 

 

Was my response useful to you? If so, please consider marking it as an Accepted Solution and/or giving it a Kudo to help other community members.

MWG+Splunk=❤
KonsSyll
Level 8
Report Inappropriate Content
Message 3 of 4

Re: Asymmetric routing for dedicated management interface

Jump to solution

@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
Reliable Contributor
Reliable Contributor
Report Inappropriate Content
Message 4 of 4

Re: Asymmetric routing for dedicated management interface

Jump to solution

@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!
Was my response useful to you? If so, please consider marking it as an Accepted Solution and/or giving it a Kudo to help other community members.

MWG+Splunk=❤
You Deserve an Award
Don't forget, when your helpful posts earn a kudos or get accepted as a solution you can unlock perks and badges. Those aren't the only badges, either. How many can you collect? Click here to learn more.

Community Help Hub

    New to the forums or need help finding your way around the forums? There's a whole hub of community resources to help you.

  • Find Forum FAQs
  • Learn How to Earn Badges
  • Ask for Help
Go to Community Help

Join the Community

    Thousands of customers use our Community for peer-to-peer and expert product support. Enjoy these benefits with a free membership:

  • Get helpful solutions from product experts.
  • Stay connected to product conversations that matter to you.
  • Participate in product groups led by employees.
Join the Community
Join the Community