SSL pass-through configuration

If you don't want to configure SSL decryption on LTM, a Performance Layer4 VIP with a FastL4 profile should work. If you do want to decrypt the client SSL and re-encrypt the server side connection, you can use a standard VIP with a client and server SSL profile. The advantage to the latter option is that you can inspect and modify the HTTP. This includes using cookie persistence. The downside is that it's extra load on the servers and LTM as both need to decrypt the SSL.

 

 

Why do you mention that you want to not use a Performance L4 VIP?

 

 

Aaron

So far I worked on SSL pass-thru apps which didn't need HTTP inspection and I configured Performance L4 VIP's. I just want to know if it is possible with standard VS and be prepared for future requests (HTTP inspection) OR HTTP inspection doesn't make any sense with ssl pass-thru as LTM will not see packets/payload (encrypted). I have tried it with standard and it didn't work.

Sure, it's possible to use a standard TCP VIP and not decrypt the SSL. It would be more efficient to use a Performance Layer 4 VIP though if you can do without SSL persistence.

 

 

HTTPS passthrough generally means not decrypting the SSL. If you don't decrypt the SSL you cannot inspect or modify the HTTP because it's encrypted.

 

 

Aaron

Aaron, can you tell me how to configure standard VIP for ssl pass-thru?

 

Our app is public facing app which is now configured as Perf. L4 VIP with Source IP persistence. The problem now is that we are seeing load on one server only as the Source Addr. is essentially our Public IP (NAT) for all Internal hosts. Any suggestions?

 

I can think of Cookie based persistence however it is Perf L4 VS.

If you want to use the efficiency of a FasL4 profile you give up the functionality of decrypting SSL using a client SSL profile and inspecting or modifying the HTTP using an HTTP profile.

 

 

If you need to load balance based on HTTP content, you would have to switch to a standard TCP VIP and add a client SSL and HTTP profile to the VIP. You could then insert an HTTP persistence cookie.

 

 

An alternative would be to use SSL session ID persistence. I think this would also require using a standard TCP VIP instead of a FastL4, but it would allow you to avoid decrypting (and re-encrypting) the SSL.

 

 

Aaron

Does this mean that I cannot use Standard VS wherein the SSL cert is on the Server only? If I use standard VS with no Client profile or a Server SSL profile, the negotiation fails and the app never works.

There are a few options (in order by what I think your requirements are):

 

 

1. Standard TCP VIP without any client or server SSL using SSL session ID persistence. No HTTP inspection or modification possible.

 

 

2. Standard TCP VIP with a client and server SSL profile. This would add load to both LTM and the servers for decrypting and re-encrypting the SSL, but would allow you to inspect and modify the HTTP on LTM and keep all traffic on the wire encrypted.

 

 

3. Use a performance layer 4 VIP and no client or server SSL profiles. This is the fastest in terms of LTM processing, but also the most limited in terms of functionality. You cannot use client or server SSL, an HTTP profile for inspection or modification, cookie insert persistence, etc.

 

 

Aaron

1. Standard TCP VIP without any client or server SSL using SSL session ID persistence. No HTTP inspection or modification possible

 

 

I had tried this however the app didnt come up with the settings (except SSL session ID persistence). This is the reason I opted for L4 VIP.

 

How do I enable SSL Session ID persistence?

When you say the app didn't come up using a standard TCP VIP and no client/server SSL profiles, what were the symptoms of the issue? Did the first request get a TCP response? Did the server receive an HTTP request? Did the client receive an HTTP response?

 

 

If you disable all but one pool member to test initially, it will remove persistence as a potential cause of the problem. Also, you can configure a custom SSL persistence profile under Local Traffic | Profiles | Persistence. You can add the persistence profile to the virtual server.

 

 

Aaron

App didnt come up -

 

I could see the 3-way handshake however the push packet after that was failing. I had seen this for 2-3 apps along with F5 support. I could also see number of ARP queries after the handshake. I felt that the SSL handshake between LTM and the server used to fail. The moment I changed it to L4 VS, everything started working fine.

 

 

10:40:13.299685 802.1Q vlan4094 P0 198.147.192.8.37702 > 192.168.20.25.https: S 216133023:216133023(0) win 64512 (DF)

 

10:40:13.300183 802.1Q vlan4094 P0 192.168.20.25.https > 198.147.192.8.37702: S 2271599220:2271599220(0) ack 216133024 win 4080 (DF)

 

10:40:13.376828 802.1Q vlan4094 P0 198.147.192.8.37702 > 192.168.20.25.https: . ack 1 win 65280 (DF)

 

10:40:13.379514 802.1Q vlan4094 P0 198.147.192.8.37702 > 192.168.20.25.https: P 1:71(70) ack 1 win 65280 (DF)

 

10:40:13.480337 802.1Q vlan4094 P0 192.168.20.25.https > 198.147.192.8.37702: . ack 71 win 4150 (DF)

 

10:40:17.887658 802.1Q vlan4094 P0 arp who-has 192.168.20.25 (Broadcast) tell 192.168.20.25

 

10:40:19.442921 802.1Q vlan4094 P0 arp who-has 192.168.20.25 (Broadcast) tell 192.168.20.25

 

10:40:29.442969 802.1Q vlan4094 P0 arp who-has 192.168.20.25 (Broadcast) tell 192.168.20.25

 

10:40:39.443503 802.1Q vlan4094 P0 arp who-has 192.168.20.25 (Broadcast) tell 192.168.20.25

 

10:40:49.443311 802.1Q vlan4094 P0 arp who-has 192.168.20.25 (Broadcast) tell 192.168.20.25

 

10:40:55.372253 802.1Q vlan4093 P0 192.168.16.6.36642 > 255.255.255.255.9030: udp 57 (DF) [ttl 1]

 

10:40:59.369788 802.1Q vlan4094 P0 198.147.192.8.48817 > 192.168.20.25.https: S 3991309693:3991309693(0) win 64512 (DF)

 

10:40:59.370284 802.1Q vlan4094 P0 192.168.20.25.https > 198.147.192.8.48817: S 1609790644:1609790644(0) ack 3991309694 win 4140 (DF)

 

10:40:59.406888 802.1Q vlan4094 P0 198.147.192.8.48817 > 192.168.20.25.https: . ack 1 win 64512 (DF)

 

10:40:59.407621 802.1Q vlan4094 P0 198.147.192.8.48817 > 192.168.20.25.https: P 1:71(70) ack 1 win 64512 (DF)

 

10:40:59.442874 802.1Q vlan4094 P0 arp who-has 192.168.20.25 (Broadcast) tell 192.168.20.25

 

10:40:59.506983 802.1Q vlan4094 P0 192.168.20.25.https > 198.147.192.8.48817: . ack 71 win 4210 (DF)

 

10:41:09.442922 802.1Q vlan4094 P0 arp who-has 192.168.20.25 (Broadcast) tell 192.168.20.25

 

10:41:35.434705 802.1Q vlan4094 P0 198.147.192.8.48817 > 192.168.20.25.https: F 71:71(0) ack 1 win 64512 (DF)

 

10:41:35.435451 802.1Q vlan4094 P0 192.168.20.25.https > 198.147.192.8.48817: . ack 72 win 4210 (DF)

 

10:41:35.435460 802.1Q vlan4094 P0 192.168.20.25.https > 198.147.192.8.48817: F 1:1(0) ack 72 win 4210 (DF)

 

10:41:35.472299 802.1Q vlan4094 P0 198.147.192.8.48817 > 192.168.20.25.https: . ack 2 win 64512 (DF)

 

10:42:05.080630 802.1Q vlan4093 P0 arp reply 192.168.16.6 is-at 0:21:28:2e:ec:69

 

10:42:05.386762 802.1Q vlan4093 P0 192.168.16.6.36642 > 255.255.255.255.9030: udp 57 (DF) [ttl 1]

 

10:42:45.190837 802.1Q vlan4094 P0 arp who-has 192.168.20.25 (Broadcast) tell 192.168.20.25

 

10:42:49.443179 802.1Q vlan4094 P0 arp who-has 192.168.20.25 (Broadcast) tell 192.168.20.25