Forum Discussion

TFleming's avatar
TFleming
Icon for Nimbostratus rankNimbostratus
Apr 17, 2020

Find connection attempts via source IP

Hey guys, I'm fairly new to F5. We have one configured before I started working here. We have a windows terminal server virtual server in our F5 that load balances between 18 different back end terminal servers. We chose this method as apposed to a windows terminal server broker for some reason.

 

We are having clients try to connect and they are getting an error. We can see through packet captures they are able to get a secure connection to our F5 virtual server, but we can't see which backend terminal server the F5 is trying to send them to. We believe the error is in relation to that backend terminal server that's a member of the pool the virtual server is associated with.

 

My question is, is there a log I can search via the clients source IP address to see connection attempts? I know they are hitting our virtual server IP, but I need to know which pool member the F5 is sending them to for authentication. I know about the "tmsh show" that will tell me about active connections, but I need to troubleshoot one step back.

  • Beaker's avatar
    Beaker
    Apr 20, 2020
    when CLIENT_ACCEPTED {
      set LogString "Client [IP::client_addr]"
      log local0. "==== $LogString (request) ====="
    }
     
    when SERVER_CONNECTED {
      log local0. "==== $LogString (server connected) - server: [LB::server addr]:[LB::server port] ===="
    }

    I have tested that this works

  • You can accomplish this with an Irule on the VIP that would log the connections and output them into the ltm log.

    Something like this should help with troubleshooting. But I would only use while troubleshooting not as a permanent addition:

    when HTTP_REQUEST {
      set LogString "Client [IP::client_addr]:[TCP::client_port] -> Requested Host[HTTP::host][HTTP::uri]"
      log local0. "==== $LogString (request) ====="
    }
     
    when SERVER_CONNECTED {
      log local0. "==== $LogString (server connected) - server: [LB::server addr]:[LB::server port] ===="
    }
     
    when HTTP_RESPONSE {
      log local0. "==== $LogString (response) - status: [HTTP::status] ===="
    }
    • TFleming's avatar
      TFleming
      Icon for Nimbostratus rankNimbostratus

      Great thank you! One quick question because I don't want to make any assumptions, will this cause an outage of any kind? Will I need to restart anything to have he iRule work?

      • Beaker's avatar
        Beaker
        Icon for Cirrus rankCirrus

        This should no impact on actual traffic as all that is happening is the F5 is logging details of the connection. Depending on the traffic load it could lead to a lot of entries in the ltm log but that is why it is recommended for troubleshooting not permanent use.

    • TFleming's avatar
      TFleming
      Icon for Nimbostratus rankNimbostratus

      One slight hickup, it's not an http request, but using RDP so a port 3389 request maybe? So I get an error when I try to apply the iRUle.

      • TFleming's avatar
        TFleming
        Icon for Nimbostratus rankNimbostratus

        ​Here is a screencap of our virtual server overview if it helps.

  • You should be able to just remove the HTTP calls from the rule I posted above like so and it should work:

    when CLIENT_CONNECTED {
      set LogString "Client [IP::client_addr]:[TCP::client_port]
      log local0. "==== $LogString (request) ====="
    }
     
    when SERVER_CONNECTED {
      log local0. "==== $LogString (server connected) - server: [LB::server addr]:[LB::server port] ===="
    }
    • TFleming's avatar
      TFleming
      Icon for Nimbostratus rankNimbostratus

      ​Sadly I still get an error "01071912:3: HTTP_REQUEST event in rule (/Common/LogLocalConnections) requires an associated HTTP or FASTHTTP profile on the virtual-server (/Common/RDS-2016-VIP)." with the above iRule.

      • Beaker's avatar
        Beaker
        Icon for Cirrus rankCirrus

        Sorry forgot to change the irule event when I edited it before. I have updated the code above. This does not use http processing events rather just tcp events