Asymmetric routing condition with two "external" networks

[Michael_57131]

(Hopefully the attached PNG file shows, the red line is how the traffic is routed now, you can see the asymmetry, and the green line is how I'd like to force all traffic between these nodes)

We recently added an external interface on the F5 (external, meaning the firewall has the route, internal meaning the firewall has a static route to the F5).

When the interface was added and the IP address configured it broke our routing. Node A (default gateway is the F5) on the 10.101.246.0/24 network sent a packet to Node B on the 10.101.104.0/24 network. Since the F5 has a connection on this network, it took the least hops and sent out the request to node B on its interface on the 10.101.104.0/24.

Node B has a default gateway for the Firewall, so it sends the unicast IP packet to the firewall's MAC. The firewall does keep track of session state, doesn't have the initiation packet (since the F5 sent it out its direct interfface) and refuses the connection, effectively ending the communication between Node A and Node B.

We only need to configure a virtual server on the 10.101.104.0/24 network that will send it's traffic to node members of a pool on the 147.101.246.0/24. The F5 doesn't need to route anything for the 10.101.104.0/24 network.

Iis there an iRule or some configuration I can put on the F5 so it will never send traffic for nodes through the 104 interface and to always send these packets to the default gateway (the FW)? We do have virtual servers on the F5 with node pool members that are on the 10.101.104.0/24 network, but I'd want even this traffic to go through the firewall. The only traffic we require from the 104 directly connected is the desitnation address for the virtual server that will be on the 104 interface.

[Michael_57131]

trying to add a static route, does not work. I can add a static route to the F5: route 10.101.104.0/24 { gateway 10.101.224.220 static } where 10.101.224.220 is the Firewall, but the connection from Node A to Node B is sent through the direct connect interface on the F5.

[nitass]

Iis there an iRule or some configuration I can put on the F5 so it will never send traffic for nodes through the 104 interface and to always send these packets to the default gateway (the FW)? We do have virtual servers on the F5 with node pool members that are on the 10.101.104.0/24 network, but I'd want even this traffic to go through the firewall.when node A is connecting to node B, does F5 do destination ip translation (i.e. host virtual server) or just forward traffic to node B (e.g. network or wildcard virtual server)? would it be possible to let F5 do only forwarding traffic for node B through firewall (e.g. network or wildcard virtual server with firewall as pool)?

[Michael_57131]

The F5 is just forwarding taffic between Node A and Node B. We have a default forwarding server configured on the Internal F5: virtual Forwarding { ip forward destination any:any mask none vlans peernet disable } where peernet is the dedicated fiber connection between the HA Pair. would it be possible to let F5 do only forwarding traffic for node B through firewall (e.g. network or wildcard virtual server with firewall as pool)? I think this is more or less what we need, how can it be done with the forwarding virtual server? I would setup a forwarding server to 10.101.104.0/24, but how can I direct that forwarding server to use the firewall (10.101.224.220 is the FW IP) as the default gateway? or the forwarding virtual server has an iRule that changes the default gateway? is that possible?

[What_Lies_Bene1]

An iRule using the nexthop command might suffice however surely the return traffic will not come via the F/W. Essentially this is a flawed and dangerous design.

https://devcentral.f5.com/wiki/iRules.nexthop.ashx

[Michael_57131]

I did try to set a route explicitly that would use the 10.101.224.220 as the default gateway for traffic to the 10.101.104.0/24 network, but the connection request from node a to node b fails still.

[What_Lies_Bene1]

Apologies I didn't real the thread fully. So, an iRule is still an option, would you like to go further with it? As I said before, this design is sub-optimal and insecure.

[Michael_57131]

I may need to read more about the iRule and insecurity. This is a temporary condition for a few months while we migrate off these pair of F5's and into a new facility where we are prepping the new F5's. When I first posted, thought the solution would look something like: 1) create a forwarding virtual server to 10.101.104.0/24 for all ports 2) Create an iRule that changes the default gateway to the firewall on interface 10.101.224.0/24 network, where the firewall IP is 10.101.224.220. 3) assign the iRule to the forwarding virtual server Then, when the LTM receives the packet from node A, for Node B (on the 104 network) with the Syn flag. the iRule changes the default gateway and traffic is routed to the firewall, the firewall sees the initial packet and so it will permit the second from Node B with the Syn-Ack flags since it's all routed through the FW.

[What_Lies_Bene1]

There are is a flaw in that plan, namely that a forwarding VS will rely on the routing table and any static route you configure will be installed with a higher metric that the route that's created by the connected interface. The default gateway can't be directly modified as such and certainly not on a per connection basis, however, this iRule (applied to a L3 or above VS) should work I think as long as NodeB also routes back via the firewall; when CLIENT_ACCEPTED { if { [IP::addr [IP::local_addr] equals 10.101.104.0/24] } { nexthop vlan_name 10.101.224.220 } }

[Michael_57131]

Node B's default gateway is the FW, I'll schedule a maintenance window and try the forwarding server with the iRule configuration.

[What_Lies_Bene1]

OK, fingers crossed.

[Michael_57131]

That worked! Thank you very much! From Node A I can telenet to Node B when I added the forwarding virtual server with the iRule. We're going to probably go with this deployment. the initial simple telnet test shows it works, I need to get some more criteria for testing with the production applications, but I'm positive it'll work. virtual zz_forwarding_104 { ip forward destination 10.101.104.0:any mask 255.255.255.0 ip protocol tcp rules nexthop_fw_224 profiles fastL4 } rule nexthop_fw_224 { when CLIENT_ACCEPTED { if { [IP::addr [IP::local_addr] equals 10.101.104.0/24] } { nexthop v224 10.101.224.220 } } }

[What_Lies_Bene1]

Great news, you're welcome. I wasn't completely confident as I've never had a need to use that command before.