For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

Greg_Burch's avatar
Greg_Burch
Icon for Nimbostratus rankNimbostratus
Jul 19, 2012

Defining "loopback" address on F5

I have an LTM pair that is only physically connected to an internal VLAN. Externally-accessible virtual servers have their own IP space that is static-routed to the non-internet-routable physical address of the F5. My problem, though, is I have a need to communicate with this LTM pair over the internet from a remote GTM device (via port 22 and 4353). I'm unable to figure out a way to essentially define a "loopback" address that I can static route to each of the devices in the HA pair (without making the LTM source monitoring checks from that address). Has anyone encountered this use case before and figured out a way to make it work?

 

 

To summarize and state in a different way, just so my point is clear:

 

 

 

Physical IPs of HA pair = 10.x.x.1, 10.x.x.2

 

Floating IP of HA pair = 10.x.x.3

 

External VIP space = 84.x.x.x static routed to 10.x.x.3

 

 

 

I want to build the following and be able to communicate with the external MGMT IPs on port 22 and 4353:

 

 

 

External MGMT IP 1 = 84.x.x.1 static routed to 10.x.x.1

 

External MGMT IP 1 = 84.x.x.2 static routed to 10.x.x.2

 

 

 

How do I configure each of the LTMs to allow SSH/iquery to 84.x.x.1, 84.x.x.2 without defining a physical VLAN?

 

config
design

5 Replies

  • nitass's avatar
    nitass
    Icon for Employee rankEmployee
    Jul 19, 2012
    have you tried to create another selfip e.g. 84.x.x.1, 84.x.x.2 on the same vlan? didn't it work?
  • Greg_Burch's avatar
    Greg_Burch
    Icon for Nimbostratus rankNimbostratus
    Jul 19, 2012
    The problem with that, though, is wouldn't the F5 then source monitoring checks from those self-IPs in addition to the 10.x.x.1 and 10.x.x.2 IPs? That would likely cause issues...
  • Eric_St__John's avatar
    Eric_St__John
    Icon for Employee rankEmployee
    Jul 20, 2012
    What about creating a VIP with the necessary IPs, and attach the following iRule: 

    
when CLIENT_ACCEPTED {
  node 10.1.1.1
}

    Eric
  • Techgeeeg's avatar
    Techgeeeg
    Icon for Nimbostratus rankNimbostratus
    Jul 20, 2012
    Hi Greg,

     

    When in the Fail-over pair the only accessible IP will be the floating IP which will point to the active unit the standby unit wont be accessible. I am sure you must have configured the NAT to the floating IP of the LTM pair. Did it work or no? if it didn't then the following may stand.

     

     

    I am not exactly sure but the commands bigip_add will not work from behind the NAT you have to get the LTM units the public IP address. I prefer you open a case with F5 and do share how you got this resolved.

     

     

    Regards,
  • nitass's avatar
    nitass
    Icon for Employee rankEmployee
    Jul 20, 2012

    Eric, cool!

     

     

    Greg, can you try what Eric suggested?

     

     

    this is my testing.

     

     

    ) list net self 10.201.59.133

     

    net self 10.201.59.133 {

     

    address 10.201.59.133/27

     

    allow-service all

     

    traffic-group traffic-group-local-only

     

    vlan internal

     

    }

     

    ) list net self|grep 84.1.1

     

    )

     

    ) list ltm virtual bar

     

    ltm virtual bar {

     

    destination 84.1.1.1:443

     

    ip-protocol tcp

     

    mask 255.255.255.255

     

    profiles {

     

    tcp { }

     

    }

     

    rules {

     

    myrule

     

    }

     

    vlans-disabled

     

    }

     

    ) list ltm rule myrule

     

    ltm rule myrule {

     

    when CLIENT_ACCEPTED {

     

    node 10.201.59.133 443

     

    }

     

    }

     

    [root@bigip:Active] config ssldump -Aed -nni 0.0 port 443 -k /config/httpd/conf/ssl.key/server.key

     

    New TCP connection 1: 10.253.114.7(41499) <-> 84.1.1.1(443)

     

    1 10 1342776301.2545 (0.0271) C>SV3.1(167) application_data

     

    ---------------------------------------------------------------

     

    HEAD / HTTP/1.1

     

    User-Agent: curl/7.15.5 (i686-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5

     

    Host: 84.1.1.1

     

    Accept: */*

     

    ---------------------------------------------------------------

     

    1 11 1342776301.2555 (0.0010) S>CV3.1(280) application_data

     

    ---------------------------------------------------------------

     

    HTTP/1.1 200 OK

     

    Date: Fri, 20 Jul 2012 09:25:01 GMT

     

    Server: Apache

     

    X-Frame-Options: SAMEORIGIN

     

    Last-Modified: Mon, 21 Nov 2011 02:51:30 GMT

     

    ETag: "172a9-ced-c3831080"

     

    Accept-Ranges: bytes

     

    Content-Length: 3309

     

    Content-Type: text/html; charset=ISO-8859-1

     

    ---------------------------------------------------------------