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

Angel_Lopez_116's avatar
Angel_Lopez_116
Icon for Altostratus rankAltostratus
May 07, 2014

Redirect traffic to one VS to another

I've been asked to redirect access to a VS to another one. The problem here is that the target VS is an HTTPS VS and the BIG-IP doesn't open the SSL so I can't configure an HTTP 301 redirect.

 

I've thought that a way to forward the connections to that VS to the other one as I can't use the HTTP redirect, is to forward it in the TCP level, using IPTABLES to forward the traffic with a rule like this:

 

iptables -t nat -A PREROUTING -p tcp -i external -d 195.235.106.196 --dport 443 -j DNAT --to 195.235.106.207

 

I don't know if there's a better way to do this or if the iptables way is not recommended for some reason.

 

Thanks.

 

application delivery
iptables
LTM
redirect

4 Replies

  • Kevin_Stewart's avatar
    Kevin_Stewart
    Icon for Employee rankEmployee
    May 07, 2014

    It's definitely going to be difficult to inject any application layer logic without decrypted access to it. You could:

     

    1. Create a NAT on the BIG-IP - more or less the same approach as your iptables idea, but within TMOS.

       

    2. Create a layer virtual server - 443 destination port, 443 destination pool, no SSL offload. This, in my opinion, is better than the first approach because you can at least load balance the back end service and apply health monitors.

       

    Both of these approaches assume you can route to the other service from the BIG-IP and you're okay making this the path to access this service.

     

    All that said, please also consider what you gain when you offload SSL at this default-deny security appliance, and what you lose when you don't. In many cases, the strict interpretation and enforcement of "end-to-end" SSL is overcome by the benefits of offloading that client side SSL to a secure proxy.

     

  • Angel_Lopez_116's avatar
    Angel_Lopez_116
    Icon for Altostratus rankAltostratus
    May 07, 2014

    Hi,

     

    Well, I've tried the iptables approach and it didn't work as expected. I have this setup:

     

    ltm virtual vs_test1 { destination 10.30.205.251:http ip-protocol tcp mask 255.255.255.255 pool pruebaszbx1 profiles { tcp { } } source 0.0.0.0/0 vlans { VLAN40 } vlans-enabled } ltm virtual vs_test2 { destination 10.30.205.252:http ip-protocol tcp mask 255.255.255.255 pool www1mobi profiles { tcp { } } source 0.0.0.0/0 vlans { VLAN40 } vlans-enabled }

     

    What I want is to forward the client connections to 10.30.205.251:http to the other VS 10.30.205.252:http

     

    In my production environment this scenario is with HTTPS not HTTP, and the SSL ends in the web server not in the BIG-IP so I can't make and HTTP 301 redirect.

     

    I'm exploring how I could do this in the BIG-IP.

     

    First try was the iptables rule... it didn't work :( connections to vs_test1 ended there and weren't redirected to vs_test2

     

    Second try was the NAT as suggested, something like this:

     

    ltm nat dnat_test { inherited-traffic-group true originating-address 10.30.205.252 traffic-group traffic-group-1 translation-address 10.30.205.251 vlans { VLAN40 } vlans-enabled }

     

    But it didn't work neither... same result as with the iptables. Client was served by vs_test1 and not vs_test2... no destination nat I think:

     

    12:24:37.830172 IP 10.30.173.102.60278 > 10.30.205.251.80: S 1891458294:1891458294(0) win 8192 12:24:37.830229 IP 10.30.205.251.80 > 10.30.173.102.60278: S 693237238:693237238(0) ack 1891458295 win 4380 12:24:37.830376 IP 10.30.173.102.60278 > 10.30.205.251.80: . ack 1 win 16425 12:24:45.560579 IP 10.30.173.102.60278 > 10.30.205.251.80: P 1:2(1) ack 1 win 16425

     

    I'd expect to see the destination address (10.30.205.251) translated to (10.30.205.252)... I guess I'm getting this wrong at some point... :(

     

    Regarding the "layer virtual server", do you mean a forwarding layer 2 or ip virtual server? I don't see how I'd configure a IP forwarding VS for resolving this scenario as the client would try to connect to 10.30.205.251 and I want to redirect that connection to 10.30.205.252. If I configure a forwarding VS... how it'd be?

     

    I know that this scenario is a bit weird, just exploring all the posibilities...

     

    Thanks!

     

  • Kevin_Stewart's avatar
    Kevin_Stewart
    Icon for Employee rankEmployee
    May 07, 2014

    I didn't actually intend to say "layer virtual server" - that was a typo. I simply meant a standard virtual server. In this case the VIP's destination would be 10.30.205.251:443, your pool would contain on member (10.30.205.252:443), and you'd need to apply a SNAT profile (Automap will do). This is assuming that .251 is a VIP address and .252 is a server address. If both are VIP addresses, then you would actually need to do a "layered VIP" approach. In the first VIP, just create your destination IP:port and the following iRule:

    when CLIENT_ACCEPTED {
    virtual internal_vs
}

    where "internal_vs" would be the physical name of the other VIP (.252).