Forum Discussion

m0j0's avatar
m0j0
Icon for Altostratus rankAltostratus
Dec 07, 2022

Policy Routing in Multi-Arm Deployment

Very new to F5, coming from a Netscaler background.

I'm deploying F5 into an environment where I have an interface in the DMZ, an interface in a private DMZ and a third interface in the trusted network.  I also have the mgmt interface connected to another network.  Currently, I have IP addresses assigned to each of these interfaces but the only route I have is the default route on the mgmt interface.  I'm wanting to configure routing such that the return traffic from any virtual server on the DMZ routes out via the DMZ gateway and any virtual server on the trusted network will route out via the trust gateway.  I've looked at an article on configuring policy based routing via iRules and assigning the iRule to each virtual server accordingly - https://support.f5.com/csp/article/K20510467

I'm just wondering if this is the only/best way to do this or if there's a more suitable option to do what I want to do.

application delivery
  • m0j0's avatar
    m0j0
    Icon for Altostratus rankAltostratus
    Dec 07, 2022

    Thanks for that information, that's awesome and exactly what I need.

    • mihaic's avatar
      mihaic
      Icon for MVP rankMVP
      Dec 07, 2022

      I know this is what you needed, as  I have been working with Netscalers in the past, too.

  • Kai_Wilke's avatar
    Kai_Wilke
    Icon for MVP rankMVP
    Dec 07, 2022

    Hi mOjO,

    using iRules its the only way setting up Policy-Based-Routing (PBR) based on SRC_IP and DST_IP. The [class match] syntax of the iRules outlines in K20510467 is just "one" example how your PBR could be setup. You may also use native [if] expressions or [switch] statement to express your needs.

    When designing such a PBR, then elect to most used routing scenario as your "default" and use F5s routing table to establish the routing as usual. The use the iRule to overwrite routing decissions based on your needs.

    when CLIENT_ACCEPTED {

	if { ( [IP::addr [IP::client_addr] equals "10.0.0.0/8"] )
	 and ( [IP::addr [IP::local_addr] equals "10.0.0.0/8"] ) } then {

		# Let the build-in routing table forward traffic for:
		#
		# src=10.0.0.0/8 to DST=10.0.0.0/8

	} elseif { ( ( [IP::addr [IP::client_addr] equals "172.16.0.0/12"] )
			  or ( [IP::addr [IP::client_addr] equals "192.168.0.0/24"] ) )
		   and ( ( [IP::addr [IP::local_addr] equals "172.16.0.0/12"] ) 
			  or ( [IP::addr [IP::local_addr] equals "192.168.0.0/24"] ) ) } then {

		# Let the build-in routing table forward traffic for:
		#
		# src=172.16.0.0/12 or src=192.168.0.0/24 to DST=172.16.0.0/12 or DST=192.168.0.0/24


	} elseif { ( [IP::addr [IP::client_addr] equals "10.0.0.0/8"] )
		   and ( [IP::addr [IP::local_addr] equals "20.20.20.0/24"] ) } then {

		# Overwrite next hop to GW=10.10.10.1 for:
		#
		# src=10.0.0.0/8 to DST=20.20.20.0/24

		nexthop 10.10.10.1

	} elseif { [IP::addr [IP::client_addr] equals "10.0.0.0/8"] } then {

		# Overwrite next hop to GW=10.10.20.1 for:
		#
		# src=10.0.0.0/8 to DST=REMAINING DESTINATIONS

		nexthop 10.10.20.1

	} else {

		# let the build-in routing table handle remaining traffic...

	}

}

    Cheers, Kai

     

     

    • Kai_Wilke's avatar
      Kai_Wilke
      Icon for MVP rankMVP
      Dec 07, 2022

      Sorry missed the part that only RETURN traffic from your VS should follow the ingress path. So yeah... AUTO Last-Hop (enabled by default) doing already the trick.

      Cheers, Kai