Forum Discussion

Nik's avatar
Nik
Icon for Cirrus rankCirrus
May 02, 2014

Logging outgoing SNAT List connections

I have a number of servers in snat lists and we're trying to figure out what servers are actually making connections. I haven't found anyplace to do this.. any ideas if it's possible?

 

8 Replies

  • I´m not sure, if I got your question right. If you are talking about incoming connections to be balanced to a pool of local servers and SNAT is applied somehow, you can use an iRule as this one (second log):

    when SERVER_CONNECTED {
         log clientside connection details to /var/log/ltm
        log local0. "Clientside connection: [clientside {IP::remote_addr}]:[clientside {TCP::remote_port}] to [clientside {IP::local_addr}]:[clientside {TCP::local_port}]"
         log serverside connection details to /var/log/ltm
        log local0. "Serverside connection: [IP::local_addr]:[TCP::local_port] to [IP::remote_addr]:[TCP::remote_port]"
    }
    

    Or are you talking about so called default SNATs?

    In this case the "clientside" part of the iRule above provides the requested information.

    Btw, I´m always trying to avoid them. Using a SNATpool in the context of a virtual server or applying SNAT via iRule provides much better control.
  • I guess, a wildcard virtual server is listening on the internal VLAN and forwards outgoing connection, right? In this case the iRule above assigned to this virtual server will log the internal server in the first log statement. The second log statement lists the used SNAT address as local address. Feel free to combine the log statements into a single one.

    An alternative approach for just monitoring the current open connection would be the "tmsh show sys conn" command.

    By specifying a client´s IP address (option "cs-client-addr") you can lookup your current connection table.

    Here is an example to display connections intiated by 10.131.131.201:
     tmsh show sys conn cs-client-addr 10.131.131.201
    Sys::Connections
    10.131.131.201:50266  10.131.131.141:80  10.131.131.131:50266  10.131.131.121:80  tcp  1  (tmm: 0)  none
    Total records returned: 1
    

    Client 10.131.131.201 tries to connect and gets SNATed by 10.131.131.131 when being connected to 10.131.131.121.

    Be carefull when using this command in the context of large connection tables, please!

    Thanks, Stephan
  • what Stephan suggested is to use virtual server (e.g. wildcard ip forwarding virtual server) with snatpool instead of snat list. so, you can setup logging in irule and assign to the virtual server.

     

    • Nik's avatar
      Nik
      Icon for Cirrus rankCirrus
      that's a really good idea, i'll give it a shot.
    • StephanManthey's avatar
      StephanManthey
      Icon for MVP rankMVP
      With the so called default SNATs I saw some changed behavior in the past and some strange side effects. That´s why I do not recommend them. In some s/w versions they forwarded traffic without a having a virtual server involved (i.e. between different DMZ VLANs). From my perspective this config item (default SNAT) is just a relict from early F5 s/w releases (4.x and below). With the introduction of TMOS v9 we´ve got pretty granular control by using SNATpools, SNAT AutoMap or SNAT via iRules. Btw, have an eye on the timeout settings and monitor the connection table and memory consumption over a long time period. If it´s continuosly growing, the default "indefinite" timeout of a SNAT might be the reason.
  • what Stephan suggested is to use virtual server (e.g. wildcard ip forwarding virtual server) with snatpool instead of snat list. so, you can setup logging in irule and assign to the virtual server.

     

    • Nik's avatar
      Nik
      Icon for Cirrus rankCirrus
      that's a really good idea, i'll give it a shot.
    • With the so called default SNATs I saw some changed behavior in the past and some strange side effects. That´s why I do not recommend them. In some s/w versions they forwarded traffic without a having a virtual server involved (i.e. between different DMZ VLANs). From my perspective this config item (default SNAT) is just a relict from early F5 s/w releases (4.x and below). With the introduction of TMOS v9 we´ve got pretty granular control by using SNATpools, SNAT AutoMap or SNAT via iRules. Btw, have an eye on the timeout settings and monitor the connection table and memory consumption over a long time period. If it´s continuosly growing, the default "indefinite" timeout of a SNAT might be the reason.