Forum Discussion

20 Replies

  • Good catch mimlo. This one should work properly with parentheses:

    when CLIENT_ACCEPTED {
     if { ! ([IP::addr [IP::client_addr] equals 10.10.10.10] or [IP::addr [IP::client_addr] equals 10.10.10.20])} {
         reject
         log local0. "Connection dropped from [IP::client_addr]"
      }
    }
    
  • good enough. It let me load this latest iRule and we are currently testing. If this works in dev then we'll apply to prod.

     

  • Stupid question but did you change the IP addresses in the rule to the two hosts that you want to permit?

     

  • Just another way of doing the same...

    when CLIENT_ACCEPTED {
      switch [IP::client_addr] {
        10.10.10.10 -
        10.10.10.20 { return }
      }
      reject 
      log local0. "Connection rejected from [IP::client_addr]"
    }
    
  • Valid question Cory, but yes, I am replacing the 10.x.x.x addresses with two external addresses with 67.x.x.x and 65.x.x.x. I'll keep working on this.

     

    • Cory_50405's avatar
      Cory_50405
      Icon for Noctilucent rankNoctilucent
      Is the iRule logging the rejection messages to /var/log/ltm from the two IP addresses you have specified that should be permitted?
  • Thanks Cory, but I think we have solved this by using this code:

     

    when CLIENT_ACCEPTED { if { not ( [class match [IP::client_addr] equals rtp_allow] ) } { reject } }

     

    This has a Data Group (rtp_allow) with the two IP address in it that are to be allowed. In testing we were able to include my IP address in this Data Group and I was able to access the internal web server page and when my IP address gets removed from the Data Group the web page is not available.

     

    • Cory_50405's avatar
      Cory_50405
      Icon for Noctilucent rankNoctilucent
      That's a good scaling solution if you want to add more addresses to it moving forward. Glad to hear you got it working.