IP Forwarding Virtual Server v/s SNAT

aaaa,

On your first point, yes you can use a SNAT object to forward traffic without the need for a forwarding IP vs. A SNAT is a listener just like a virtual server (and a NAT too).

N

nathan, thank you for a quick response.

For argument sakes, lets say we have two nodes 10.10.10.1 and 10.10.10.2 that need to talk to 8.8.8.8 (internet) and an on-campus public server 65.66.67.68. Their vserver is 190.191.192.193. The LTM needs to be configured in such a way that traffic sourcing from the private nodes destined to 8.8.8.8 should always be SNAT'd and traffic destined to 65.66.67.68 should never be SNAT'd. Is that something we can by creating a SNAT object, i.e. selective SNAT.

For testing, i created a SNAT object, added the two private nodes in the inside address list and, and gave their vserver as the outside address. "tmsh show /sys connection" showed all traffic sourced from the nodes being SNAT'd to their vserver address. We do want traffic to get SNAT'd but only for destinations off-campus. Is there any way to do that by creating a SNAT object.

Would really appreciate any suggestions/pointers to my second question. Thanks!

For testing, i created a SNAT object, added the two private nodes in the inside address list and, and gave their vserver as the outside address. "tmsh show /sys connection" showed all traffic sourced from the nodes being SNAT'd to their vserver address. We do want traffic to get SNAT'd but only for destinations off-campus. Is there any way to do that by creating a SNAT object.

can you try something like this? only virtual server is used (no snat list) but upstream device needs to have route or arp for 190.191.192.193 (to bigip).

root@(ve11c)(cfg-sync In Sync)(Active)(/Common)(tmos) list ltm data-group internal node_address
ltm data-group internal node_address {
    records {
        10.10.10.1/32 { }
        10.10.10.2/32 { }
    }
    type ip
}
root@(ve11c)(cfg-sync In Sync)(Active)(/Common)(tmos) list ltm data-group internal campus_address
ltm data-group internal campus_address {
    records {
        65.66.67.68/32 { }
    }
    type ip
}
root@(ve11c)(cfg-sync In Sync)(Active)(/Common)(tmos) list ltm rule qux
ltm rule qux {
    when CLIENT_ACCEPTED {
  if { [class match -- [IP::client_addr] equals node_address] } {
    if { [class match -- [IP::server_addr] equals campus_address] } {
      snat none
    } else {
      snat 190.191.192.193
    }
  }
}
}

Would really appreciate any suggestions/pointers to my second question.

it may be easier if you can provide some example.

For testing, i created a SNAT object, added the two private nodes in the inside address list and, and gave their vserver as the outside address. "tmsh show /sys connection" showed all traffic sourced from the nodes being SNAT'd to their vserver address. We do want traffic to get SNAT'd but only for destinations off-campus. Is there any way to do that by creating a SNAT object.

can you try something like this? only virtual server is used (no snat list) but upstream device needs to have route or arp for 190.191.192.193 (to bigip).

root@(ve11c)(cfg-sync In Sync)(Active)(/Common)(tmos) list ltm data-group internal node_address
ltm data-group internal node_address {
    records {
        10.10.10.1/32 { }
        10.10.10.2/32 { }
    }
    type ip
}
root@(ve11c)(cfg-sync In Sync)(Active)(/Common)(tmos) list ltm data-group internal campus_address
ltm data-group internal campus_address {
    records {
        65.66.67.68/32 { }
    }
    type ip
}
root@(ve11c)(cfg-sync In Sync)(Active)(/Common)(tmos) list ltm rule qux
ltm rule qux {
    when CLIENT_ACCEPTED {
  if { [class match -- [IP::client_addr] equals node_address] } {
    if { [class match -- [IP::server_addr] equals campus_address] } {
      snat none
    } else {
      snat 190.191.192.193
    }
  }
}
}

Would really appreciate any suggestions/pointers to my second question.

it may be easier if you can provide some example.

oops, sorry it should be IP::local_addr rather than IP::server_addr.

ltm data-group internal node_address {
    records {
        10.10.10.1/32 { }
        10.10.10.2/32 { }
    }
    type ip
}
ltm data-group internal campus_address {
    records {
        65.66.67.68/32 { }
    }
    type ip
}
ltm rule qux {
    when CLIENT_ACCEPTED {
  if { [class match -- [IP::client_addr] equals node_address] } {
    if { [class match -- [IP::local_addr] equals campus_address] } {
      snat none
    } else {
      snat 190.191.192.193
    }
  }
}
}

oops, sorry it should be IP::local_addr rather than IP::server_addr.

ltm data-group internal node_address {
    records {
        10.10.10.1/32 { }
        10.10.10.2/32 { }
    }
    type ip
}
ltm data-group internal campus_address {
    records {
        65.66.67.68/32 { }
    }
    type ip
}
ltm rule qux {
    when CLIENT_ACCEPTED {
  if { [class match -- [IP::client_addr] equals node_address] } {
    if { [class match -- [IP::local_addr] equals campus_address] } {
      snat none
    } else {
      snat 190.191.192.193
    }
  }
}
}

So, if we want to do selective snat, a forwarding vserver and irule is the way to go. Cannot do this by only creating a snat object and specifying inside/outside addresses.

it may also be possible but i normally prefer using virtual server because it is more granular (i.e. irule) and it is single point of configuration (i.e. virtual server).

in case you want to use virtual server and snat list, you may create performance layer4 virtual server listening on campus subnet and use gateway pool which allow-snat is disabled. so, traffic destined to campus subnet will hit this virtual server and be sent to the pool. since snat is not allowed on the pool, snat list is not applied. this is just one example of possible configuration. ;-)

So, if we want to do selective snat, a forwarding vserver and irule is the way to go. Cannot do this by only creating a snat object and specifying inside/outside addresses.

it may also be possible but i normally prefer using virtual server because it is more granular (i.e. irule) and it is single point of configuration (i.e. virtual server).

in case you want to use virtual server and snat list, you may create performance layer4 virtual server listening on campus subnet and use gateway pool which allow-snat is disabled. so, traffic destined to campus subnet will hit this virtual server and be sent to the pool. since snat is not allowed on the pool, snat list is not applied. this is just one example of possible configuration. ;-)

nitass,

Tested the rule above. It looks like, unless the vserver used for SNAT'ing (snat 190.191.192.193) is not defined in a SNAT pool (apart from being a vserver object), the rule did not work. As soon as it was defined as a SNAT object, it started working.

For my second question, lets consider the same two nodes 10.10.10.1 and 10.10.10.2 and their standard vserver 190.191.192.193 port 25. The listener object 190.191.192.193 is also inside a SNAT pool. If its not, like i said, i couldn't see it working, but i may be wrong or missing something. Lets say node 10.10.10.1:8821 needs to talk to an off-campus public server 170.171.172.173:25. The request hits the wildcard forwarding vserver that has the above irule and the node gets SNAT'd to its vserver address (190.191.192.193:8821). When the public server responds back 170.171.172.173:25, the destination address is the vserver address 190.191.192.193:8821 (and not port 25, like its defined on the LTM). At this point, does the traffic get forwarded to the node 10.10.10.1:8821 or does it get load balanced to the pool instead (as is the case with a standard vserver). We currently have just one standard vserver:25 and a wildcard forwarding vserver on our LTMs.

Would really appreciate if you could throw some light on it. Best practices, recommendations, anything :)

Hi nitass, please let me know if you need any more explanation for the above scenario or if i'm compeltely wrong.

Also, does an IP forwarding vserver maintain the connection's state in LTM's connection table (tmsh show /sys connection)? Thanks.