Forum Discussion

Mark_60861's avatar
Mark_60861
Icon for Nimbostratus rankNimbostratus
Jul 22, 2011

Emulate v4.5 SNAT behavior with 10.x

I'm trying to emulate BIGIP 4.5 SNAT behavior for a set of legacy hosts that are being migrated from a 4.5 bigip box to a 10.x BigIP LTM.

With a 4.5 SNAT things work as follows:

All connections that the server initiates outbound using the bigIP as it's default gateway are SNATed to the snat IP.

All connections inbound to the server, initiated by a client, say an admin ssh'ing into the server, are simply forwarded without any NAT/SNAT. (this would be an asymmetrical flow, bigip only sees half the connection.)

In 10.2.1 I've created an irule and forwarding server (see below) that SNATs connections from a 'legacy server' data class. However, currently the 10.x BigIP SNATs everything it sees... This includes flows that it never saw an initial SYN for...

For example, if you ssh into a server, you have asymmetrical routing, so all packets from the ssh client go router -> server, while the return path is server -> bigip -> router.

This prevents ssh'ing into the box as a 3way handshake is never established, the ssh client sends a SYN which reaches the server, the server replies next-hoping the syn/ack to the bigip. The bigIP then SNATs the connection before sending it to the router, which of course prevents the 3way handshake.

Some detailed information and diagrams of what's going on, as well as my current irule and forwarding server configuration.


VLAN205 = Servers, 10.10.205.0/24
VLAN210 = VIPS, 10.10.210.0/24
Default Gateway for BIG-IP Route Domain: Router interface on VLAN 210.
Default Gateway for Servers: Big-IP Interface on VLAN 205.
                    +-----------------------+
                    |                       |
                    |     VIP VLAN 210      |
                    |    10.10.210.0/24     |
                    |                       |
                    +-----+--------------+--+
                          |              |
                          |              |
           +--------------+--+         +-+--------------+
           |                 |         |                |
           |    BIG-IP       |         |    Router      |
           |                 |         |                |
           +--------------+--+         +-+--------------+
                          |              |
                          |              |
                    +-----+--------------+---+
                    |                        |
                    |     SERVER VLAN 205    |
                    |     10.10.205.0/24     |
                    |                        |
                    +----------+-----------+-+
                               |           |
                               |           |
                         +-----+--+      +-+-------+
                         |        |      |         |
                         | Server |      |  Server |
                         |        |      |         |
                         +--------+      +---------+
class legacy_servers {
   {
      host 10.10.205.103
      host 10.10.205.104
   }
}
rule SNAT-TEST-RULE-1 {
   when CLIENT_ACCEPTED {
  if { [class match [IP::client_addr] equals "legacy_servers"] && ( [IP::protocol] == 6 || [IP::protocol] == 17 ) } {
        log local0. "=============================================================="
        log local0. "SNAT'ed Legacy Server: [IP::client_addr] to 10.10.210.50"
        log local0. "IP::client_addr: [IP::client_addr]"
        log local0. "IP::local_addr: [IP::local_addr]"
        log local0. "IP::remote_addr: [IP::remote_addr]"
        log local0. "IP::protocol: [IP::protocol]"
        snat 10.10.210.50
  }
}
}
profile fastL4 route_friendly_fastl4 {
   defaults from fastL4
   loose initiation enable
   loose close enable
}
virtual VS-FORWARD-RD0 {
   ip forward
   destination any:any
   mask 0.0.0.0
   rules {
      SNAT-TEST-RULE-1
   }
   profiles route_friendly_fastl4 {}
   vlans {
      VLAN205
   } enable
}

4 Replies

  • The one 'hack' of a solution i've come up with is only snat if the client_port (server in this case) is in the ephemeral port range, obviously this is highly OS dependent, however this may work in my case as we're a solaris, linux, and windows shop.

    It's far and away less than ideal, seems like there should be a better solution.

    
    when CLIENT_ACCEPTED {
      if { ( [class match [IP::client_addr] equals "legacy_servers"] ) && ( [IP::protocol] == 6 || [IP::protocol] == 17 ) }  {
            log local0. "=============================================================="
            log local0. "New connection from Legacy Server: [IP::client_addr]"
            log local0. "IP::client_addr: [IP::client_addr]"
            log local0. "IP::local_addr: [IP::local_addr]"
            log local0. "IP::remote_addr: [IP::remote_addr]"
            log local0. "IP::protocol: [IP::protocol]"
            log local0. "TCP::local_port: [TCP::local_port]"
            log local0. "UDP::local_port: [UDP::local_port]"
            log local0. "TCP::client_port: [TCP::client_port]"
            log local0. "UDP::client_port: [UDP::client_port]"
             IANA Ephemeral port range: 49152-65535 (Windows uses this)
             Linux Ephemeral port range: 32768-61000
             Solaris Ephemeral port range: 32768-65535
             IF the client_port is above 32768 we will assume it's an ephemeral connection
             from the legacy server and SNAT it.
            if { ([TCP::client_port] > 32768 || [UDP::client_port] > 32768) }  {
                log local0. "!!! client_port seems to be Ephemeral"
                log local0. "!!! SNAT'ed Legacy Server: [IP::client_addr] to 10.10.210.50"
                use snatpool LEGACY-SERVER-SNAT
            }
        }
    }

  • Hi Mark,

     

    Why couldn't you point the default route towards the router? That way if the VIP is accessed and ultimately sent to the legacy servers it would be SNAT'd?

     

     

    Bhattman

     

  • That would be a far better solution. However, The problem with that is that this is a firewalled legacy environment. All the firewall rules have been written for the traffic flows as they are currently. Coming up with new firewall rules is near impossible at this point given the nature and age of some of these applications.

     

  • Hi Mark,

     

    I think it might be possible to use the following command located on the following link http://devcentral.f5.com/wiki/iRules.nexthop.ashx This should allow you to direct the legacy server towards a next hop which could be the router .

     

     

    Bhattman