HTTP and HTTPS in one VS

Forums Technical Forums
, , ,
1

Hi,

Is it possible to do this via Irule.

Client sends to port 80,443 >> Proxy listen on 8080 and forward to LTM on 8080>> LTM VS listen on port 8080 and forward to 80,443

Thanks

2

Hi,

why do you want to do this with one VS ?

Regards, Sören

3

Yes one listening VS on port 8080 and expect that ltm can distinguish if traffic is 80 or 443 and forward 80 to pool_80 and 443 to pool_443

4

Hi,

I would rather have more than one VS for this. Both VIPs can listen with the same IP so you end up with the same result just a lot less overhead from an iRule to filter and make the load balancing decisions. Unless you have a spesific reason why it has to be one VIP?

5

Just a thought, can the proxy add a custom header to say whether it was port 80 or 443? If so an Irule on the VS could then interrogate the header and forward accordingly.

Hope this helps, N

6

@Derekv, would be good, but nope customer requirement is one VS @Nathan, no proxy before LTM only listen on 8080 and forward on 8080 as well

7

look at this:

oneVS

8

If a customer’s requirements don’t make sense, you should point this out. What you ask is possible, but it is not worth the trouble both to create and to maintain and support it. YOu can have multiple VS with the same IP address as long as they are listening on different ports. That is the easy way to do this. Otherwise, you can write irules that check the port, or any custom headers you specify and then call the pool command to send to whatever pool you want.

9

If a customer’s requirements don’t make sense, you should point this out. What you ask is possible, but it is not worth the trouble both to create and to maintain and support it. YOu can have multiple VS with the same IP address as long as they are listening on different ports.

That is the easy way to do this. Otherwise, you can write irules that check the port, or any custom headers you specify and then call the pool command to send to whatever pool you want.

10

You can really just boils this down to the following:

when CLIENT_ACCEPTED {
    if { [TCP::local_port] == 80 } {
        SSL::disable
        pool myPool
    } elseif { [TCP::local_port] == 443 } {
        pool myPool
    } else { 
        discard 
    }
}

Make sure to apply an SSL profile to the VIP and set the port to * (any).

11

I agree with everyone else that it’s better to use a separate virtual server per protocol. That said, if the customer wants one VS, you can use an iRule like this to support it:

Aaron

12

Multiple VIPs is certainly the better option, but sometimes a requirement is just a requirement. I’d also add that while the above iRule should work, the discard statement inside the CLIENT_ACCEPTED event still allows a client to perform a full three-way handshake with the VIP (before being rejected). If you don’t want this, then the better option is perhaps a carefully written packet filter rule - although separate VIPs with specific listening ports will give you the same thing.

13

I think the link provided is doing this

Client 80,443 >>>>>>> Vs 8080 |LTM| >>>>>> 80,443

Setup is somewhat like below… Need some help to distinguish port 80 and 443 from received 8080 port.

Client 80,443 >>>>>>> 8080 |Proxy Server| 8080 >>>>>>> Vs 8080 |LTM| >>>>>> 80,443

Thanks

14

A few additional questions then, for clarification:

  1. You’re expecting the LTM VIP to process SSL and non-SSL traffic on a single port (8080)? This is still technically possible, but considerably more difficult to achieve.

  1. Is the proxy server transparent? Forward? Reverse? Necessary?

  1. And is necessary to have the LTM listen on 8080 and not 80 and 443?

15
  1. Yes client requesting internet will pass through 8080.
  2. client >>> forward proxy server >>> LTM >>> Internet
  3. Yes, client requesting the internet 80,443 to forward proxy in port 8080 then forward proxy server send request to LTM in port 8080.
16

Ahh, so you’re implementing a FORWARD proxy for internal clients to access the Internet. That’s a little different. Here are a few considerations:

  1. First and foremost, I tend to believe that the LTM would make more sense on the inside of the forward proxy (perhaps to load balance multiple proxies), otherwise I’m not 100% clear on what the LTM is doing.
  2. An explicit, non-transparent forward proxy requires configuration settings in the client browser (in this case to point to the proxy on port 8080). The proxy therefore TUNNELS all traffic (80/443) through the port 8080 connection. So,
1 - browser makes connection to proxy on port 8080

2 - browser issues HTTP CONNECT method, asking proxy to make SSL tunnel to origin web server

3 - proxy resolves DNS hostname for origin server

4 - proxy makes connection to origin on port 443

5 - proxy replies to browser ""HTTP/1.0 200 Connection established"" to tell the browser that the SSL tunnel has been established.

6 - browser and origin do SSL certificate exchange.  Proxy is used, but just as a tunnel - SSL certificate info is not modified in any way by the proxy

7 - browser sends ""GET /"" to origin server (via SSL tunnel through proxy) with host header filled out by browser.  Again, proxy does not modify host header, as data is just being ""tunneled""

** 10077499: How does Forward Proxy work when the browser is going to a secure (SSL) website?

  1. It makes sense in that regard that you’re trying to do 80 an 443 in a single LTM VIP, but a) the proxy would connect to the LTM on the native port - 80 or 443, and not 8080, and b) again, unless you’re doing something unique I still think the LTM should be on the other side of the forward proxy.
  2. Finally, unless you’re providing significant web caching and/or content filtering on your forward proxy, there’s both a published iRule and an iApp that will allow the LTM to perform forward proxy.
17

Technically yes, but it would be very difficult and I don’t really think that’s the point. A forward proxy will attempt to first resolve and then directly connect to the remote Internet host, and on the origin port. Unless I’m still missing something, you’d either have to 1) modify the proxy to resolve all remote hosts to the LTM VIP, and then have the LTM perform the real DNS lookup and forward the request, or 2) put the LTM in forwarding mode, in which case it wouldn’t matter what port or protocol was going through it. In no case can I imagine that the forward proxy would forward traffic to another device on the same proxy port (8080).