local virtual server as pool member
1 Topic
Pool used with HSL::open - what are the requirements? Any way to make it send using TLS?
Hi - we have a vendor integration that captures and logs request and response data for calls to virtual servers via an iRule that uses HSL::open/HSL::send. For this, they have us: Creating a local HTTP port 80 virtual server, with an SSL server profile and their TLS collection server endpoints as members; and, Creating a logging pool that has that local HTTP virtual server as a member; and, Creating an iRule (which they provide) that does an HSL::open on that logging pool, and after formatting request/payload/response data, does an HSL::send That formatted data then goes to the logging pool entry, which in turn sends it to the port 80 VIP, which in turn sends it, using TLS, to their collection servers. I'm assuming that their iRule is therefore responsible for formatting the stream sent to the logging pool into valid HTTP, which then just gets passed "raw" to their HTTP VIP, without any processing by the logging pool. (Is that a correct understanding?) My questions are: 1. Given that scheme, why can't the iRule skip the "logging pool", and just use the pool for the port 80 virtual server directly in the HSL::open? What value is added by having the iRule pass the stream being sent through a separate pool? If the content the iRule will send via the HSL::send is HTTP formatted anyway (my assumption), couldn't the HSL::send just as simply send it right to the pool for the virtual server? And, if it does so, is there any way to configure the virtual server to not even expose a port? 2. Alternatively - and even better - is there any way to configure the "logging pool" created above to send directly to the vendor's TLS collection servers - that is, do a TLS wrapping on the way out? (this may be tantamount to asking, is there any way to attach an SSL server profile to the pool, even though it doesn't have an owning virtual server, causing it to apply TLS)? The reason I ask is two-fold - their design is clumsy for us in that the logging pool can't directly send to the local VIP via the TMM plane (because of the issue described here), and as a result we have to add a static route to force the traffic out the management interface, increasing network load; and, having another VIP exposing port 80 is undesirable as a security risk (though we can and have blocked access to it ... still, we'll get serious side-eye from cybersecurity) Thank you for any information!Solved119Views0likes2Comments