Forward Proxy + SSL Termination

normelton

We're using an A10 vThunder as a forward proxy for users. So the users live on the "inside" of our environment, reaching out to the Internet. We use a wildcard VIP to route all of their traffic, with a policy to permit/block certain hostnames. Works great.

There's also a requirement to terminate the SSL session for a particular destination hostname, inject a header, re-encrypt, and send it along its way. We own the certificate, so no problems there.

I can imagine two ways of doing this, neither of which work (yet) ...

• In policy, create a classlist to match the desired hostname, then attach a client SSL profile + aFlex. But the policy language appears limited to forward/drop. No obvious way to terminate SSL.
• Create a second VIP for the IP address of the destination server. Except I can't re-use the same IP address for the "backend" server.

Any other suggestions?

john_allen

There is a whole product that does this: A10 Thunder SSLi. (https://www.a10networks.com/products/thunder-ssli/)

normelton

https://community.a10networks.com/discussion/comment/17231#Comment_17231

So I started down this rabbit hole, but it seemed specific for routing the decrypted traffic through an external appliance for analysis. I’ll revisit it.

mdunn

The high level approach should be along these lines. However, you say that you own the certificate. Is the certificate a trusted internal certificate for re-signing public certs/keys? This is the usual use-case for forward proxy policy control. If you own the cert/keys for the actual destination server, then this approach changes, and we would use "server-name domain certificate key" in the client-ssl template, which should be much simpler.

wildcard VIP 
  Virtual Port
    template policy  <- web access control
    template client-ssl   <- decryption, see details below
    template http    <- header insertion
    template server-ssl <- encryption, see caveat below

Client-SSL Template

Within the client-ssl template, configure "forward-proxy-inspect class-list cl_decrypt_domains" to define specific destinations for decryption. Other destinations will bypass decryption. Again, if we own the certificate and key for the server destination, we would instead use "server-name domain certificate key".

Server-SSL Template

As you noted, a traditional SSLi deployment involves routing the decrypted traffic through a decrypt zone. The traffic egresses the decrypt zone routing back to the A10 for encryption on another wildcard VIP. If you have no need for the "decrypt zone", binding a server-ssl template to the vport should encrypt the traffic before egressing the A10.

normelton

Ahh okay interesting. So I managed to accomplish this with two different virtual servers. One with a client/server SSL policy + aflex rule. This handles the one domain for which we own the server-side certificate. That allows us to decrypt/reencrypt the traffic and apply the aflex rule.

The other virtual server has a policy template that permits/denies individual domains that are to be routed without decryption.

Each virtual server is front-ended with an IP ACL that steers traffic to the single website into the first virtual server, with all remaining traffic into the second.

I'll check out your suggestion, that might allow us to roll everything into a single VS. Certainly simpler!