IdP3.3.0/Big IP F5

[Mailvaganam, Hari]

Hello Greg!

Thank you for your post.

> Clustered how?  We run several behind an F5; the primaries (we run several different configurations) are in a an active/standby config using priority groups.

We have 5 servers behind the F5 – each with a single IdP (clustering of session is via the DB).

> Do your LTM logs have anything useful?

Our F5 SME says no. Attached below is the F5 config used over here as an FYI.

We are engaging F5 vendor support as well – hopeful based on their experiences, they can help us eliminate the red herrings quickly (there are many). It may not be F5 related – but they would have had seen something similar in past and more quickly narrow down.

This post is out of topic for this user group per say – apologies – the replies have been very helpful (and good to have the comradery).



VIP

ltm virtual SHIB3_VIP.443 {
    destination 206..xx.xxx.xx:https
    ip-protocol tcp
    mask 255.255.255.255
    partition ubc-ents01
    persist {
        /Common/cookie {
            default yes
        }
    }
    pool SHIB3_PROD_AUTH_ID_443
    profiles {
        /Common/_oneconnect_ubc_default { }
        /Common/http-x-forward-for { }
        /Common/serverssl-insecure-compatible {
            context serverside
        }
        /Common/tcp { }
        authentication.ubc.ca_SSL {
            context clientside
        }
    }
    source 0.0.0.0/0
    source-address-translation {
        pool ents01-snat-pool02
        type snat
    }
    translate-address enabled
    translate-port enabled
    vs-index 703
}

Pool

ltm pool SHIB3_PROD_AUTH_ID_443 {
    members {
        SHIB3_idp1.:https {
            address 10.7.0.xxx
            session monitor-enabled
            state up
        }
        SHIB3_idp2.:https {
            address 10.7.0.xxx
            session monitor-enabled
            state up
        }
        SHIB3_idp3.:https {
            address 10.7.0.xxx
            session user-disabled
            state up
        }
        SHIB3_idp4.:https {
            address 10.7.0.xxx
            session user-disabled
            state up
        }
        SHIB3_idp5.:https {
            address 10.7.0.xxx
            session user-disabled
            state up
        }
    }
    monitor /Common/_https_ubc_default
    partition ubc-ents01
}



Best regards,

Hari
_________________________________________
Hari Mailvaganam
Access Application Architect, Identity and Access Management
UBC Information Technology
The University of British Columbia
Office: 604-827-5117  | Cell: 604-836-4489
Web: www.it.ubc.ca
Skype: harimailvaganam


From: users <users-bounces at shibboleth.net> on behalf of Greg Haverkamp <gahaverkamp at lbl.gov>
Reply-To: Shib Users <users at shibboleth.net>
Date: Thursday, July 6, 2017 at 8:17 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: IdP3.3.0/Big IP F5

On Thu, Jul 6, 2017 at 6:41 PM, Mailvaganam, Hari <hari.mailvaganam at ubc.ca<mailto:hari.mailvaganam at ubc.ca>> wrote:
Wondering if anyone has set up a clustered IdPv3 behind BIG IP's F5?

Clustered how?  We run several behind an F5; the primaries (we run several different configurations) are in a an active/standby config using priority groups.

We have one over here – that is experiencing the occasional ERR_CONNECTION_RESET – we are peeling of the layers F5 config, Apache setting, network etc to zero in on the potential cause.

If anyone has this set up on F5 – wondering if can compare our F5 config, Apache settings etc.

Our set up:

·  Apache proxy traffic via AJP to Tomcat
·  SSL to Big IP/F% -- and SSL again to the server endpoints (both Gandi)
·  HSTS commented out on Apache; SELinux disabled (for troubleshooting)
My setup is sufficiently different to provide little direct help.  We terminate TLS on the BigIP, run everything through a dispatching iRule, and go in the clear to the Jetty IdPs (everything lives on a dedicated IAM network and hardware), no Apache httpd.

Do your LTM logs have anything useful?  We did at one point have problems with virtual servers flapping; we (i.e., I) had scheduled health checks too regularly, and apparently the BigIPs couldn't handle it and bogged down, marking first one and then eventually the other pool members down, occasionally both, which would take the virtual servers offline.  And then people would get reset connections. (There was more than just the IdP's; still, I remain surprised that high-frequency health checks would do that.)

Greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20170707/57b62203/attachment-0001.html>