Apache port number appearing in URL on redirects

EDIT: RESOLVED

EDIT: Replaced 8443 with 8043 (to fix potential port number conflict with Shibboleth SP)

I am trying to change Apache (apache 2.4) to listen on port 8080 and 8043 instead of 80 and 443 (so I don't need sudo/root to start it). The F5 BigIP load balancer device in front listens on 80 and 443 though, and will load balance the end-users to 8080 and 8043 on the web servers.

However, when a Web Browser goes to our site (e.g. https://foo.bar/) our apache configurations cause it to redirect with the 8043 port number! (e.g. https://foo.bar:8043/baz/). This of course times out (since foo.bar resolves to the F5 BigIP device's IP, which has nothing on port 8043).

The relevant Apache Config looks like this:

<Proxy balancer://UM>
        Order deny,allow
        Allow from all
        BalancerMember ajp://10.25.145.130:8010 route=a keepalive=On disablereuse=On
        BalancerMember ajp://10.25.145.131:8010 route=b keepalive=On disablereuse=On
        ProxySet lbmethod=bybusyness stickysession=UMLB nofailover=Off
        SetEnvIf Cookie UMLB HAVE_UM_ROUTE
        Header add Set-Cookie "UMLB=x.%{BALANCER_WORKER_ROUTE}e;path=/;" env=!HAVE_UM_ROUTE
</Proxy>

<Proxy balancer://IDP>
        Order deny,allow
        Allow from all
        BalancerMember ajp://10.25.145.130:8009 route=a keepalive=On disablereuse=On
        BalancerMember ajp://10.25.145.131:8009 route=b keepalive=On disablereuse=On
        ProxySet lbmethod=bybusyness stickysession=IDPLB nofailover=Off
        SetEnvIf Cookie IDPLB HAVE_IDP_ROUTE
        Header add Set-Cookie "IDPLB=x.%{BALANCER_WORKER_ROUTE}e;path=/;" env=!HAVE_IDP_ROUTE
</Proxy>

<VirtualHost *:8043>
        ServerName foo.bar
        DocumentRoot /var/www/html

        ProxyPass /idp balancer://IDP/idp
        ProxyPass /UserManagement balancer://UM/UserManagement

        SSLEngine on
</VirtualHost>

EDIT (additional info):

Looking at the HTTP Trace (chrome addon) I see there are several redirects which all work fine, but once it gets here it fails and redirects with port 8043 in the end (which is why it fails, if I manually remove :8043 in the URL after the redirect it works)

GET https://foo.bar/idp/AuthnEngine
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36
Referer: https://foo.bar/idp/profile/SAML2/Redirect/SSO?SAMLRequest=blahblahblah
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8,de;q=0.6
Cookie: JSESSIONID=blahblahblah; _idp_authn_lc_key=blahblahblah; IDPLB=x.b; BIGipServerblahblah=blahblahblah

HTTP/1.1 302 Moved Temporarily
 Redirect to: https://foo.bar:8043/UserManagement/private/Login?redirectURL=blahblahblah
Date: Tue, 05 Jan 2016 18:32:32 GMT
Expires: 0
Cache-Control: no-cache, no-store, must-revalidate, max-age=0
Pragma: no-cache
Set-Cookie: _pid_domain=blahblah; Domain=bar.com; Path=/; Secure
Location: https://foo.bar:8043/UserManagement/private/Login?redirectURL=blahblahblah
Content-Length: 0
Keep-Alive: timeout=15, max=98
Connection: Keep-Alive
Content-Type: text/plain; charset=UTF-8

Since the Back-End tomcat app is giving the Redirect with 8043 in there, I figured ProxyPassReverse is the right solution to fix, so I tried the following: (did not work, same results)

ProxyPass /idp balancer://IDP/idp
ProxyPassReverse /idp https://foo.bar/idp

ProxyPass /UserManagement balancer://UM/UserManagement
ProxyPassReverse /UserManagement https://foo.bar/UserManagement

Also tried the following (same results):

ProxyPass /idp balancer://IDP/idp
ProxyPassReverse /idp balancer://IDP/idp

ProxyPass /UserManagement balancer://UM/UserManagement
ProxyPassReverse /UserManagement balancer://UM/UserManagement

Even tried a bogus URL for the ProxyPassReverse, just to see if it had any effect, and it DOES NOT! The HTTP Trace results are the same, it does nothing to adjust the URL on the back-end app's redirects.

What is going on here?

Thanks,
Ben