LTM Multiple Default Routes?

OK, first let's make sure we're talking about the right feature, since we have 2 ways to perform source address translation -- NAT (Click here) & SNAT (Click here).

 

 

Do you just need your servers to be assigned a publicly routable address for outbound requests, or do you also need to be able to initiate inbound connections to those servers on a publicly routable address?

 

 

/deb

I am hoping I can depend on NATs (not SNATs) to establish a publicly routable IP address for the pool members on the private side. The NAT mapping is 1:1.

 

 

What I need is for the NAT from each zone to egress out a particular gateway, not just the default gateway. I also need the NAT to accept inbound traffic ruling out SNATs.

 

 

So, taking for example some fictious IP addresses to illustrate my example, there are two firewalled zones (attached to a firewall with these two subnets plus an external Internet routable subnet) to which each of the public zones independently connect.

 

 

12.1.37.1 is the firewall interface/gateway for the first zone, which for the sake of clarity has a public/shared assigned IP of 12.1.37.28. 12.1.39.1 is the firewall interface/gateway for the second zone.

 

 

The respective private zone (only published on the BigIP) for the 12.1.37.0/24 subnet has a subnet of 192.168.37.0/24 that will have NATs (1:1) such that a server/pool member with an IP of 192.168.37.5 maps to 12.1.37.5.

 

 

I desire the traffic from the NAT 12.1.37.5 to always egress through the firewall gateway of 12.1.37.1.

 

 

Incoming requests to the pool members will be serviced by a virtual server, and let's assign 12.1.37.4 for the virtual server. Using the last hop feature, I am guaranteed that traffic inbound from the 12.1.37.1 gateway to the virtual server 12.1.37.4 and eventually the pool member 192.168.37.5 will always egress back the route it came, independent of the BigIP's default route, which say for the sake of clarity is 12.1.39.1.

 

 

I have this working properly for virtual servers and pool members when the traffic originates from the gateway address of 12.1.37.1 or when the source IP is in the same subnet as the public side of the 12.1.37.0/24 IP space. What I am missing is the behavior where 12.1.37.5's traffic (originating from the pool member 192.168.37.5) egresses through 12.1.37.1 given the BigIP's default route is established through 12.1.39.1.

 

 

Additionally, there are virtual servers on the 12.1.39.0/24 network and respective pool members in the 192.168.39.0/24 subnet. These pool members need to egress (when traffic originates from a 192.168.39.0/24 address) through the gateway 12.1.39.1.

 

 

I'm a bit at a loss as how to establish different routes for NATs based on the source subnet (or VLAN IP address subnet as per assigned through the BigIP user interface).

 

 

Thank you for the reply! I am excited to learn if there's way to accomplish this goal, even if it requires some elaborate reconfiguration for one of the private subnets.

 

 

Michael

Hi Michael --

OK, I think I get what you're going for now.

And a picture being worth a thousand words...

             I
             /\
            /  \
           /    \
   ---------    ---------
   12.1.37.1    12.1.39.1
   ---------    ---------
        |          |
        |          |
  ------------------------
  |         LTM          |
  ------------------------
       |             |   
 192.168.37.x    192.168.39.x
 nats out to      nats out to
 12.1.37.x          12.1.39.x

& you want to ensure outbound traffic from 192.168's are routed out the corresponding gateway?

I don't think a default gateway pool would choose the more local of the 2 addresses for each connection, but you could try that first.

If that doesn't do it, then create this iRule:

when CLIENT_ACCEPTED {
  set failed 0
  if {[IP::addr [IP::client_addr] equals 192.168.37.0/24]}{
    node 12.1.37.1
  } elseif {[IP::addr [IP::client_addr] equals 192.168.39.0/24]}{
    node 12.1.39.1
  }
}
when LB_FAILED {
  if {$failed == 0}{
    if {[IP::addr [IP::client_addr] equals 192.168.37.0/24]}{
      log local0. ".37. gateway not responding, trying .39."
      node 12.1.39.1
    } elseif {[IP::addr [IP::client_addr] equals 192.168.39.0/24]}{
      log local0. ".39. gateway not responding, trying .37."
      node 12.1.37.1
    }
    set failed 1
  } else {
    discard
    log local0. "both gateways down, can't forward, discarding ([IP::client_addr]:[TCP::client_port])"
  }
}

Configure a wildcard forwarding virtual server (0.0.0.0:0, mask 0.0.0.0, type Forwarding(IP), Proto=All, enabled only on the 2 server-facing vlans) and apply the above iRule to it.

The rule will choose the correct gateway, choose the other if no response, and silently drop the connection if both are down, logging the event in the ltm log to assist in troubleshooting. (Note: You can use only the CLIENT_ACCEPTED portion of the iRule if you don't want to fall back to the other gateway.)

The NATs will take place on egress as configured.

I didn't push any traffic through the rule, but it passed a syntax check applied to a forwarding virtual server.

HTH, and I'd be very interested to hear how that works out for you.

/deb

Hi

 

 

I created an irule from the first section:

 

 

when CLIENT_ACCEPTED {

 

set failed 0

 

if {[IP::addr [IP::client_addr] equals 192.168.37.0/24]}{

 

node 12.1.37.1

 

} elseif {[IP::addr [IP::client_addr] equals 192.168.39.0/24]}{

 

node 12.1.39.1

 

}

 

}

 

 

and applied this to the wildcard virtual server and only to an individual VLAN and it worked! I did some thorough testing by adding and removing and it is definitely working.

 

 

Thank you very much!

 

 

Mike

You're very welcome.

 

 

I'm surprised at how popular this solution is, actually...

 

 

Welcome aboard!

 

 

/deb

This solution is definitely a winner for me. I have a similar network configuration, and this fixed my issue.

I had a chance to test this out and for some reason it does not work.

 

 

I can see actions like a telnet reach the virtual server but the traffic does not seem to be forwarded.