Secure site giving problems

the problem is this happens whenever you click on anything in the site it goes back to the original home page..

this is what i get from the SSLDUMP

 

 

 

22 7 13.0221 (12.8559) C>S application_data

 

22 8 13.0402 (0.0180) C>S application_data

 

22 9 13.1254 (0.0852) S>C application_data

 

22 10 13.1263 (0.0008) S>C application_data

 

22 11 19.0617 (5.9354) C>S application_data

 

22 12 19.0789 (0.0171) C>S application_data

 

22 13 19.1596 (0.0807) S>C application_data

 

22 14 19.1599 (0.0002) S>C application_data

 

18 30.1445 (30.0457) S>C TCP FIN

 

22 15 26.7116 (7.5517) C>S application_data

 

22 16 26.7380 (0.0263) C>S application_data

 

22 17 26.8225 (0.0844) S>C application_data

 

22 18 26.8227 (0.0002) S>C application_data

 

New TCP connection 23: psaofmrvb5.mtn.co.za(41295) <-> esf.mtn.co.za(20160)

 

New TCP connection 24: psaosbrvb3.mtn.co.za(45132) <-> esf.mtn.co.za(20175)

 

24 1 0.0006 (0.0006) C>S SSLv2 compatible client hello

 

Version 3.1

 

cipher suites

 

TLS_RSA_WITH_RC4_128_MD5

 

SSL2_CK_RC4

 

TLS_RSA_WITH_RC4_128_SHA

 

TLS_DHE_DSS_WITH_RC4_128_SHA

 

TLS_ECDH_ECDSA_WITH_RC4_128_SHA

 

Unknown value 0x4e

 

TLS_RSA_WITH_AES_128_CBC_SHA

 

TLS_RSA_WITH_AES_256_CBC_SHA

 

Unknown value 0x4b

 

Unknown value 0x4c

 

TLS_RSA_WITH_3DES_EDE_CBC_SHA

 

TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

 

TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA

 

TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA

 

Unknown value 0x50

 

TLS_RSA_WITH_DES_CBC_SHA

 

TLS_DHE_DSS_WITH_DES_CBC_SHA

 

TLS_DHE_RSA_WITH_DES_CBC_SHA

 

TLS_ECDH_ECDSA_WITH_DES_CBC_SHA

 

Unknown value 0x4f

 

TLS_RSA_EXPORT1024_WITH_RC4_56_SHA

 

TLS_DHE_DSS_WITH_RC2_56_CBC_SHA

 

TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA

 

TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA

 

TLS_RSA_EXPORT_WITH_RC4_40_MD5

 

SSL2_CK_RC4_EXPORT40

 

TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA

 

TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA

 

TLS_RSA_EXPORT_WITH_DES40_CBC_SHA

 

TLS_DH_anon_WITH_3DES_EDE_CBC_SHA

 

TLS_DH_anon_WITH_RC4_128_MD5

 

TLS_DH_anon_WITH_DES_CBC_SHA

 

TLS_DH_anon_EXPORT_WITH_RC4_40_MD5

 

TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA

 

TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA

 

TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA

 

TLS_RSA_EXPORT_WITH_DES40_CBC_SHA

 

TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA

 

24 2 0.0007 (0.0000) S>C Handshake

 

ServerHello

 

Version 3.1

 

session_id[32]=

 

d5 91 33 41 e8 7c d9 c7 3e 70 ee f5 c3 82 a9 93

 

e6 71 96 cb 4b 90 47 b0 6e 1f 7a ef 2e 82 d4 57

 

cipherSuite TLS_RSA_WITH_RC4_128_SHA

 

compressionMethod NULL

 

24 3 0.0007 (0.0000) S>C Handshake

 

Certificate

 

24 4 0.0007 (0.0000) S>C Handshake

 

ServerHelloDone

 

24 5 0.0031 (0.0024) C>S Handshake

 

ClientKeyExchange

 

24 6 0.0031 (0.0000) C>S ChangeCipherSpec

 

24 7 0.0035 (0.0003) C>S Handshake

 

24 8 0.0062 (0.0027) S>C ChangeCipherSpec

 

24 9 0.0062 (0.0000) S>C Handshake

 

24 10 0.0072 (0.0010) C>S application_data

 

24 11 0.0072 (0.0000) C>S application_data

 

24 12 0.0076 (0.0003) C>S application_data

 

New TCP connection 25: psaofmrvb4.mtn.co.za(52045) <-> esf.mtn.co.za(20160)

 

25 0.0192 (0.0192) C>S TCP FIN

 

25 0.0197 (0.0004) S>C TCP FIN

 

New TCP connection 26: psaofmrvb4.mtn.co.za(52046) <-> esf.mtn.co.za(20160)

 

24 13 0.3411 (0.3334) S>C application_data

 

24 14 0.3412 (0.0000) S>C application_data

 

24 15 0.3412 (0.0000) S>C application_data

 

22 19 29.1491 (2.3263) C>S application_data

 

22 20 29.1654 (0.0162) C>S application_data

 

22 21 29.2472 (0.0818) S>C application_data

 

22 22 29.2481 (0.0008) S>C application_data

 

Okay, your post before last was helpful. You indicate that, after logon, any link you click generates the same exact POST request and returns back to the home page. At this point it's very likely that the application logic doesn't like what it's getting from the proxy and is trying to get the user back on track. Your best bet then into compare the initial requests and responses to the site, up to and including this POST request in both the proxied and non-proxied environments.

 

 

You didn't answer whether the virtual server was using an iRule or any special configuration(s).

 

 

Also, if you turn off client side SSL on the BIG-IP does it make a difference?

 

I have a irule that rewrites the content in the XML WSDL to https. this is the config https (Client side) http (server side) this is my config

 

 

 

ltm virtual vs_soa_bpm_prd {

 

destination 10.217.235.116:20176

 

ip-protocol tcp

 

mask 255.255.255.255

 

partition SOA

 

persist {

 

/Common/dest_addr {

 

default yes

 

}

 

}

 

pool pool_soa_bpm_prd

 

profiles {

 

/Common/mtn.co.za {

 

context clientside

 

}

 

/Common/oneconnect { }

 

/Common/tcp { }

 

SOA_Profile { }

 

SOA_expression { }

 

}

 

rules {

 

Streaming_SOA_Prod

 

/Common/CRM

 

}

 

snat automap

 

vlans-disabled

 

}

 

Hmmm, that doesn't sound like a great idea to me considering that the HTTP Content Length header won't be modified to match the increased size. This probably explains your issue with the client constantly reposting; it's not accepting the response as valid. Could you modify your server configuration or WSDL to return https:// links instead?

this was the requirements i received from the solutions architect. this is the what the irule does...

 

 

when HTTP_REQUEST {

 

 

STREAM::disable

 

HTTP::header remove "Accept-Encoding"

 

}

 

when HTTP_RESPONSE {

 

 

if {[HTTP::header value Content-Type] contains "text"}{

 

 

STREAM::expression {@http://esf.mtn.co.za@https://esf.mtn.co.za@}

 

 

STREAM::enable

 

}

 

}

 

Yep, that'll break things pretty well I'd say although I'd expect it to break things straight away, not just after you authenticate. Do you initially connect using http?

all communications on the client side is done https

That may or may not be true depending on your version. Prior to 9.3 you might need to set the Rechunking option in the HTTP profile, but that shouldn't be the case anymore with STREAM expressions.

 

 

https://support.f5.com/kb/en-us/solutions/public/6000/400/sol6422.html

 

 

So what it looks like you're trying to do is replace all instances of the HTTP URL with HTTPS. The stream profile will look at payload. You can set the Redirect setting in the HTTP profile to either ALL or MATCHING to get the BIG-IP to replace HTTP references in 30x redirects. Otherwise, you still need to compare the request and response traffic between the working and non-working environments. My guess is that you're either not catching something in your iRule, or some other value is slipping through/changing that the application can't use.

Figured out what was wrong. in my streaming profile i had source http destination https instead of a blank profile...