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

Dos2_206331's avatar
Dos2_206331
Icon for Nimbostratus rankNimbostratus
Jul 10, 2015

Forwarding ssl to secondary VIP based on uri:port

Hellow all

In test environment, to preserve public IPs, we advertise multiple urls with to the same public IP, e.g.: 1.1.1.1 test1.com test2.com test3.com And on firewall translate 1.1.1.1 to private IP of the primary VIP.

I need a primary VIP only doing forwarding ot seconday VIP, based on combination of uri and port number ot different secondary VIPs, something like:

test1.com:8001 -> secondary-vip-1
test1.com:8002 -> secondary-vip-2
tets2.com:8002 -> secondary-vip-3
test3.com:8004 -> secondary-vip-4

Client ssl profile, anlyitics, etc. are on the secodnary VIPs, and prmimary VIP only doing forwarding. I tried the following iRule and also tried polices and it seems to be workign only when I disable ssl. Can you please help? 

when HTTP_REQUEST { 
switch [HTTP::host] {
     test1.com:8001 { virtual secondary-vip-1 } 
     test1.com:8002 { virtual secondary-vip-2 }
     tets2.com:8002 { virtual secondary-vip-3 } 
     test3.com:8004 { virtual secondary-vip-4 }
     default { discard }
  }
}
application delivery
deployment
design
devops
iRules
LTM
traffic-policies

5 Replies

  • giltjr's avatar
    giltjr
    Icon for Nimbostratus rankNimbostratus
    Jul 10, 2015

    Does test1.com have a valid ssl client profile?

    Also I would think you may want to redirect before a HTTP request was made. So I'm not sure if you can do "virtual" in CLIENT_ACCEPTED or if it would matter that much, but could you try:

    when CLIENT_ACCEPTED {
switch [TCP::local_port] {
            8001 { virtual secondary-vip-1 }
            8002 { virtual secondary-vip-2 }
            8003 { virtual secondary-vip-3 }
            8004 { virtual secondary-vip-4 }
           default { discard }
    } 
}
  • Dos2_206331's avatar
    Dos2_206331
    Icon for Nimbostratus rankNimbostratus
    Jul 10, 2015

    Thank you for your response. I realised that the problem the match condition when using ssl. When SSL enabled nothing is being forwarded to secondary VIPs. Also the problem in the solution above is that I need to match on url+port number (two different URL may use the same port number).

     

  • Kevin_Stewart's avatar
    Kevin_Stewart
    Icon for Employee rankEmployee
    Jul 10, 2015

    Is the client performing SSL or are you just enabling SSL between inside and outside VIPs?

     

  • Dos2_206331's avatar
    Dos2_206331
    Icon for Nimbostratus rankNimbostratus
    Jul 11, 2015

    I need SSL between clinet and secondary (inside) VIP and the secondary VIP and server. I dont really need SSL on the primary (outside) VIP, but if have I guess I can enable it. The reason is that the outside VIP is only test environment to preserve public IPs. The idea is to keep the secondary (inside) VIPs exactly the same as production.

     

  • Kevin_Stewart's avatar
    Kevin_Stewart
    Icon for Employee rankEmployee
    Jul 11, 2015

    Okay, so if I understand, your primary external VIP needs to simply tunnel the client's SSL session to the secondary internal VIP(s). So here's the deal:

     

    1. If the client is establishing an SSL session with the secondary VIP, the primary VIP only sees encrypted traffic and CANNOT filter on URL. It can only see the IP and port.

       

    2. If the client is establishing an SSL session with the secondary VIP, then it is the secondary VIP's client SSL profile that matters. It frankly doesn't make any sense to do unencrypted traffic between the client and primary VIP and SSL between the primary and secondary.

       

    It may be that you can solve your external IP address issue in a better way:

     

    1. A single wildcard or subject alt name (SAN) cert on your ONE VIP that decrypts client side SSL, optionally re-encrypts on the server side, and sends traffic to different pools based on request URI or hostname).

       

    2. Do the same as above with SNI (server name indication) - a TLS extension whereby the client presents a unique hostname in it's ClientHello message.