LTM Authentication Profile LDAP Cert Feature in APM?
Hello again, Since our customer tries to migrate from LTM auth profiles to APM he's missing one feature in APM which was available in LTM auth profiles. The customer is checking in the LDAP if a certificate is available, here's the relevant config setting: Does someone know how to implement the same in APM? Thanks, Peter1.4KViews1like10CommentsLTM Policy with Rewrite profile forward to specific Node
The issue I am currently facing is in the common partition I have a profile rewrite and an LTM policy in place working perfectly and has no issues. I have tried to replicate this in a different partition with the exact same steps and it is not working. We have a virtual server: VS_Azure1.aeltc.com_10.205.1.xxxabc.aeltc.com10.205.1.xxx443 (HTTPS)StandardEdit...DMZ And we have a pool: pool_abc.aeltc.com3DMZ In this pool we have 3 different nodes ( running 3 different services ) The profile rewrite looks like this: Client uri: https://abc.aeltc.com/aegis/tt/api/ > server uri: https://ae-iapp01-tt.office.aeltc.org/AEGIS10/api/ Client uri: https://abc.aeltc.com/catering/tt/api/ > server uri: https://uniwareintegration-tt.office.aeltc.org/api/ The above are 2 examples, so the LTM policy I have tried to configure is: If when browsing to abc.aeltc.com they add /aegis/tt/api/ then send the traffic to node one always. If when browsing to abc.aeltc.com they add /catering/tt/api/ then send the traffic to node two always. I have attempted to do this via LTM however the policy isn't working it still load balances via the pool? Any help would be deeply apricated.1.2KViews0likes11CommentsLTM :: Zero Window Server Side :: TCP Profiles
We have a virtual server setup for our receiving mail system, and it has been configured as-is for quite some time (measured in years). Never before has an issue arisen, but recently a particular client has been having problems sending attachments to us (and as far as we are aware, ONLY that client). What they claim to see is that the connection is terminated. Normal email works fine. Small file attachments work fine. However when they send us attachments that are Mb in size, the connection will not be successful. On our side, we see the window size slowly creep down until it hits zero. The BIG-IP probes the mail system, the mail system acks the probe, but keeps the window size at zero. It does this until the zero window timeout is reached on the BIG-IP and the connection is terminated by the BIG-IP (TCP RST). This is what the window decrease looks like on the client side (tcp.stream eq 3 and ip.src eq [the mail system]): This is what the window decrease looks like on the server side (tcp.stream eq 2 and ip.src eq [the VIP]): Client side end of the connection: Server side end of the connection: My impression initially was that this is not a BIG-IP problem... but when we remove the BIG-IP from the path, the connection works fine regardless of attachment size. Again, works fine for everyone else as far as we know regardless of if the BIG-IP is in the path... which is perplexing. Things I've tried: * Switching-out TCP profiles (lan optimized, wan optimized, client and server matching and different in combinations of the above). Now on mptcp-mobile-optimized with defaults. * Moving TLS off of the F5 * Resetting TLS profile to defaults * Different mail systems (of same type/configuration) Current configuration: * VIP on port 25 * TCP profile with mptcp-mobile-optimized w/defaults * SSL Profile (defaults w/cert, optional SSL, allowed cipher suites) * SMTPS Profile (allows TLS) * Pool w/single mail system * iRule w/VIP bounceback * Source IP Persistence VIP bounceback iRule: when LB_SELECTED { if {[IP::addr "[IP::client_addr]/24" equals "[LB::server addr]/24"]} { snat automap } else { snat none } } Any ideas/thoughts/suggestions all welcome. Thanks for taking the time.905Views0likes1CommentLTM Authentication Profiles EOL?
Hi all, I have a customer which is making intensive use of LTM Authentication Profiles. We are told by our F5 representative when v13 was released this time that LTM auth profiles will be EOL some day. I told my customer he should plan to go to APM to use auth in LTM. Now we're on v16 and the LTM auth profiles seem still to be available. I couldn't find any information about when LTM auth profiles will be EOL. Can someone from F5 enlighten me so that I can give this information to the customer? Thank youSolved753Views0likes2CommentsF5 SDK Python - Assign HTTP Profile to VIP
Hi, can someone draw me an example how can I assign HTTP profile to existing VIP? I am seeing that ipProtocol key is tight to tcp profile but I do not see any key that has http profile assigned when queering VIP configuration. I am little bit lost here.668Views0likes3CommentsRewrite Profile JSON error
Hey Everyone, We are using a rewrite profile to do the following: Converting Client URI = https://customer.company.com/loginpage/ to Server URI = https://login.company.com/ Everything looked fine but some users i guess have more access on the backend and are getting a JSON error. Should I be using Irules instead?Solved663Views0likes3Comments"tmsh list ltm virtual" not showing the attached iRules
Hi, I dont see the attached iRules to a VS when I run the command "tmsh list ltm virtual" Any thoughts on this ? Whats the best command to see the list of VS on a LTM along with attached profiles, irules and what not. Thanks, MSK425Views0likes13CommentsSSL issue
Hello there, We have a F5 LTM and a virtual server configured to a server in port 443, the topology is: Computer --> F5 LTM --> switch --> server When we try to connect to the server through https we saw the message "Connection reset" in the browser, but if we try to connect without passing the F5 the connection is successful. We don't have configured any SSL client profile or server. This is the configuration on F5: #Virtual Server #________________________________________________________________________________ ltm virtual /Common/Server1 { destination /Common/10.1.5.X:443 ip-protocol tcp mask 255.255.255.255 pool /Common/Server1 profiles { /Common/tcp { } } source 0.0.0.0/0 translate-address enabled translate-port enabled } #________________________________________________________________________________ #Pools #________________________________________________________________________________ ltm pool /Common/Server1 { members { /Common/10.1.7.X:443 { address 10.1.7.X } } monitor /Common/https_443 } #________________________________________________________________________________ #Profiles #________________________________________________________________________________ # -Default Profile- ltm profile tcp tcp { ack-on-push enabled close-wait-timeout 5 congestion-control high-speed deferred-accept disabled delayed-acks enabled ecn disabled fin-wait-timeout 5 idle-timeout 300 keep-alive-interval 1800 limited-transmit enabled max-retrans 8 nagle disabled proxy-buffer-high 49152 proxy-buffer-low 32768 proxy-mss disabled proxy-options disabled receive-window-size 65535 reset-on-timeout enabled selective-acks enabled send-buffer-size 65535 slow-start enabled syn-max-retrans 3 time-wait-recycle enabled time-wait-timeout 2000 timestamps enabled } As you can see, we don't have any SSL client or server profile and we tried changing "translate-port" to disabled and "Source Address Translation" to auto map but none of these work. Also we made a tcpdump and we can see the TCP Reset from 10.1.7.X (tcpdump.png) and some curl (curl.png), openssl (openssl.png and openssl2.png) and a telnet (telnet.png). Hope you can help us to find out what's going on. Thank you.400Views1like1Comment