Antonio: The Tomcat server has no knowledge of the F5, or that it is being fronted by an Apache HTTP Server. I do SSL termination in Apache HTTP Server, and clear-text from HTTP to Tomcat. My redirect port for the normal HTTP listen in Tomcat is commented out. <Connector port="18080" protocol="HTTP/1.1" connectionTimeout="20000" /> <!-- A "Connector" using the shared thread pool--> <!-- <Connector executor="tomcatThreadPool" port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" /> -->
Andre: The URL I am using is https://loadbalancer.domain.com It is listening on port 80 and 443, if you hit 80, internally it redirects you to 443. No SSL cert on the F5 load balancer. It simply sends the traffic to one of the two HTTP servers (round-robin, also tried persistence, no difference). The HTTP server is listening only for HTTPS on 23270/tcp. Hitting https://loadbalancer.domain.com I see my "Hello world!" which is all that is in index.html. This is the DocumentRoot of HTTP, and *not* proxied over at this time. Only /SelfService and /static are proxied /static just being my test of static content, but still served up by Tomcat. It's exactly 30 seconds before the page cannot be loaded when trying anything proxied to Tomcat, but also accessed via the F5 load balancer. Not sure where the 30 seconds comes from; perhaps a load balancer time out, as I dont see a "30" in my httpd configurations or my tomcat server.xml There should be nothing between them to hinder it. We have many load balancers and this one specifically you dont need to open any firewall requests for the specific networks the HTTP servers are on. I did have to get the firewall opened up to allow me to hit https://loadbalancer.domain.com because the VIP for "loadbalancer.domain.com" is in the DMZ, and my Desktop & VPN networks cannot hit it on 80/443 without opening holes. But beyond that, any connection from the F5 to the HTTP Server should be 100% open bi-directional, since same subnet. On Tue, Feb 21, 2017 at 2:05 PM, Antonio S. Cofino <cofi...@gmail.com> wrote: > Aaron, on tomcat instances change the redirectPort attributte on the http > conectó to the loabbalancer's port 443 > > My guess is that your webapp has restriction rule requesting SSL con > fidntial channel. Therefore the non-confidential to the 18080 port from the > balancer are redirected to the 23270 port, but it should be 443. > > Antonio > > > > El 21/2/2017 19:46, "Aaron Gray" <aaronmg...@gmail.com> escribió: > > I have an application server from a vendor that comes bundled with an > additional Apache Tomcat server. The webapp SelfService.war is vendor > supplied too. > > Here's my problem (IP's replaced to protect the innocent): > > networks: > DMZ=172.x.x.x > INTERNAL=10.x.x.x > > server1 https listen = 172.1.1.1:23270 > server2 https listen = 172.1.1.2:23270 > F5 load balancer hostname = loadbalancer.domain.com:443 > backend tomcat server = 10.1.1.1:18080 > > mod_proxy configuration: > ProxyPass /SelfService http://10.1.1.1:18080/SelfService > ProxyPassReverse /SelfService http://10.1.1.1:18080/SelfService > > When I access these DMZ webservers which mod_proxy back to Apache Tomcat > as: > https://172.1.1.1:23270/SelfService > and > https://172.1.1.2:23270/SelfService <https://172.1.1.1:23270/SelfService> > They load properly. Perfectly, every time! > > When I access these DMZ webservers via the F5 load balancer (to which I > dont have access to, but the network folks configure for me), it hangs. > Eventually returns: > https://loadbalancer.domain.com:23270/SelfService > cant load. > > No idea why the URL is being re-written with the ":23270". > I added static content to the server.xml on 10.1.1.1 (Tomcat) to test: > <Context docBase="/path/to/tomcat/static" path="/static" /> > Then put a simple index.html in there. Accessing via the Apache Web > Servers works fine, but if you hit it with the Load Balancer it once again > adds the https://loadbalancer.domain.com:23270/static > > Do you have any thoughts? Thanks so much, I have been working with this > for weeks now with no success >