Encrypting HTTP traffic to SSL on LTM

Question

We're about to leverage our LTM's for a partnership, and need to know how to take unencrypted traffic and encrypt it.&nbsp;
&nbsp;Basically what we're doing is:&nbsp;
&nbsp;-Traffic will come in from our partner via HTTPS.  Big-IP will serve as the SSL termination point, convert the packets to HTTP, change the port number (to a pre-defined port, let's say 4000) that the server is listening on, and forward them off to the servers (which cannot read or interpret HTTPS packets).  This entails setting up a client SSL thing.
&nbsp;-The servers will then respond with HTTP traffic over, again let's say port 4000 after they have processed the data, at which time the LTM will take the unecrypted data, re-encrypt it, and send it as HTTPS traffic via port 443 to our partner.  This requires a server SSL configuration.&nbsp;
&nbsp;Now the twist:&nbsp;
&nbsp;-The servers will also need to proactively send HTTP traffic to our partner without first receiving a packet that the LTM has decrypted.  We need the LTM to proactively encrypt that data that comes in as HTTP over...again, let's say 4000, and then send it off to our partner as HTTPS traffic over port 443.  The servers can't do it, because the app can't do it.&nbsp;
&nbsp;I read somewhere that SNAT plays a role in this last twist, but I can't seem to find the forum post again.  Is there a solution article out there that details how we can do this?  Or has anyone done it, and can provide a blow-by-blow of what we need to do to make it work?&nbsp;

hooleylist · Answer

Hi, 
&nbsp;  
&nbsp; For the partner (HTTPS) -&gt; LTM -&gt; (HTTP) app traffic you can create a virtual server on port 443 with a client SSL profile pointing to a pool of the server(s) on port 4000.  The replies will follow the reverse path.  If your server(s) have their default gateway set to the LTM floating self IP, you don't need SNAT.  If that's not the case, then use SNAT on the virtual server. 
&nbsp;  
&nbsp; For the app (HTTP) -&gt; LTM -&gt;  (HTTPS) partner traffic, you can create an HTTP virtual server with a server SSL profile pointing to a pool of the partner server(s) on port 443.  You'll need to use SNAT on this virtual server.  You'll also need a TMM route (or default route) to get to the partner network. 
&nbsp;  
&nbsp; Aaron

quintious_74258 · Answer

OK, so even if the servers are not responding to the partner's packets, and the packets aren't returning through an existing connection in BIG-IP, we still use a server ssl profile and it will automatically encrypt traffic that the LTM is seeing for the first time?  I just want to make sure I'm understanding this correctly, because the LTM essentials  course was stating that server ssl profiles were for "return" traffic - it didn't say anything about fresh traffic that's being initiated internally.

quintious_74258 · Answer

Double post, feel free to delete this one.&nbsp;

hooleylist · Answer

Replies are handled by the original virtual server the request went through.  However, if you have both sets of hosts originating traffic, then you need two virtual servers.   
&nbsp;  
&nbsp; For the VS which handles your requests to the partner, you use a server SSL profile to encrypt the LTM to partner pool traffic.  For the VS which handles the partner requests to you, you use a client SSL profile to decrypt the requests and re-encrypt the responses on the clientside of LTM. 
&nbsp;  
&nbsp; Aaron

quintious_74258 · Answer

Alright, thanks, we'll give it a shot.  
&nbsp;  
&nbsp; (And will probably still open a sev. 3 ticket to help walk us through it anyways, since we're paying for the premium support :P).

Forum Discussion

Encrypting HTTP traffic to SSL on LTM

Recent Discussions

self-directed requests fail because of no certificate

Decode ObjectSID from Base64-encode string

iRule - Url rewrite and header replace and pool selection not working

ip x-forwarding

F5 ASM API-Protection Policy

Related Content

Encrypted cookies on strict uri

Inspecting Oauth2 or SAML https traffic by the ASM

Logging TLS traffic less than TLSv1.2

Traffic Shaping and Atlassian Jira

Floating IPs on new traffic group members

ABOUT DEVCENTRAL

RESOURCES

SUPPORT

PARTNERS