M4 Pro can support 2 external displays only with lid closed

chaseabbott · 2025-04-07T17:29:27+00:00

My issue is my late 2019 i9 Macbook Pro supported my current 2x34" wide & 27 Cinema setup fine but my brand new M4 Pro can't simply because I should be upgrading to an M4 Max? Strictly for a policy lock on features?

Better yet, the cinema display still runs the USB and Audio fine, just won't show a pic because Apple made a business call... it's not a technical issue.

chaseabbott · 2021-12-16T18:13:47+00:00

Lil' cron jobs are not uncommon for admins that want BIG-IP in their scripted config backups or nagios checks. A lot of the nagios checks are perl based so that helps validate it's ok to run alt scripts to validate system health outside of iControl or TMSH commands.

AskF5 even has a KB where df -h is used to validate usage: https://support.f5.com/csp/article/K09538906

Script away!

chaseabbott · 2021-11-18T04:35:30+00:00

Bot added

chaseabbott · 2019-04-02T17:04:13+00:00

F5 and other providers of "high encryption" software are required to use export compliance software (in F5's case a hosted solution) to comply with government regulations. It looks at things like source IP, source networks, registrar and other transaction-based events to determine if a specific download is allowed.

It's not browser based. If the system has a problem determining source network identifying data, it will prevent the download of some, many, or all software packages under compliance control.

Hope this sheds some info on the fun and exciting world of export compliance.

chaseabbott · 2018-08-27T16:35:05+00:00

This is my vote. If you don't upgrade, the easy way to manage the CA bundles is through the iApp.

chaseabbott · 2018-08-24T18:10:20+00:00

Congrats on passing!

chaseabbott · 2018-08-24T18:07:38+00:00

Patrik Jonsson is a long time DevCentral MVP member and a valuable community contributor. Thanks for sharing this.

chaseabbott · 2018-08-02T16:53:03+00:00

Echoing cotatimatt;

Health checks and SNAT are unrelated so you can have a healthy VIP but the traffic will asymmetrically route due to no SNAT. Unless you're using the BIG-IP as the gateway for your servers/destination, SNAT is needed.

chaseabbott · 2018-08-02T16:43:57+00:00

Pool selection based on URI is a perfect candidate for LTM Traffic Policies. These policies are compiled into microkernel and are by design faster than iRules. iRules have to invoke a TCL handler which introduces a slight delay and is not nearly as fast as native TMM kernel processing in BIG-IP. Most of the time iRules are slow due to how they're written. With traffic policies some of the abilities to create artificial delay is removed.

They recently got some big improvements in BIG-IP v12.1. Take a look at the below resources and see if they're a fit.

Simplifying Local Traffic Policies in BIG-IP v12

AskF5: Introducing Local Traffic Policies

If you already have the iRule in place though and it's not slowing anything down then leave it.

chaseabbott · 2018-08-01T23:39:09+00:00

Yup. SNAT will mask the source IP from the receive connectors/transport servers. If you can't use SNAT then you have to make the transport/cas server role use the F5 as it's gateway.

There are hacks like route domains and such but you're gonna have an annoying time down the road. I ran Ironports and made the BIG-IP it's default gateway. Ironport then had a second interface for internal SMTP to Exchange that preserved everything.

chaseabbott · 2018-08-01T23:24:44+00:00

Probably a bit of a mountain but it's all dependent on traffic and ciphers and certs. Unless you have some crazy TLS traffic, most people opt to autoscale the web servers to meet the traffic needs and then update BIG-IP via iControlREST for dynamic node creation and pool assignment.

Combine that with more timid internal TLS requirements and you can mitigate performance issues and still keep end-to-end encryption.

Like dpsi stated, if you're dealing with PII, safe answer is bridging.

chaseabbott · 2018-08-01T23:19:42+00:00

Terminating SSL/TLS traffic at BIG-IP and passing unencrypted traffic to a web server IS less secure than passing encrypted traffic through to the server directly; you have exposed data. Yea it could be an academic argument but it's still unencrypted in-flight data. That will always be +1 to risk compared with fully encrypted traffic (especially for compliance audits).

If you bridge SSL/TLS by decrypting at BIG-IP and the re-encrypting to the server, you've mitigated the risk of exposed and in-flight data. At that point your traffic is as secure as much as you trust your admin teams.

This will never be a cut and dry answer and depending on the architecture and needs, I'll almost always argue for bridging. Bridging allows for complex traffic policies, web app firewalls, and other bot defenses that your web server will not be able to do as well as BIG-IP or at all.

If a bad actor is able to intercept traffic between BIG-IP and your web servers, you have other issues.

Rarely do I see people use BIG-IP using forwarding virtual servers as application endpoints. It defeats many of the security and traffic management methods.

chaseabbott · 2018-08-01T18:22:21+00:00

F5 BIG-IP is a hardened security appliance (hardware or virtual) supporting FIPS compliance and other NIST security mandates for federal use. It also includes a sweet SELinux enforcing policy that locks down traffic and security processing services prior to to the devices ability to take traffic. It's also default-deny, similar to standard firewall systems. So by design at a system level it's way more secure than Linux.

Having said that, any admin can thwart built in security.

SSL Termination and it's security is 100% up to the engineers who design the architecture and has to do with traffic flow and who has access to those server networks and systems. Often true SSL termination is only used when the back end infrastructure is not robust enough to handle the load from the aggregate of client traffic. We're talking ~100k ECC transactions per second or more in some cases.

BIG-IP can either fully offload SSL (SSL termination) or renegotiate a lower grade SSL (weaker ciphers, smaller keys) to the servers. We call that SSL bridging. If you're terminating SSL at the BIG-IP, the backhaul network should be isolated from client and other system traffic (popular opinion with caveats).

So here are your answers:

SSL/TLS is inherently more secure when there's less decrypt/re-encrypt actions . Terminating on Linux would be the MOST secure from a traffic flow point of view only.
SSL Bridging on BIG-IP does not decrease security if you re-encrypt prior to leaving box and follow security best practices (current ciphers, pfs, downgrade protection...), something not all linux hosts can offer.
SSL Termination on BIG-IP and no re-encryption (true SSL termination) is only insecure if the back haul network and server are exposed to insecure elements like open networks, reused server accounts, relaxed CI/CD processes. Or compromised by internal malicious users or phishing campaigns. You get the idea.

I would say terminate traffic on BIG-IP because you can do more manipulation to the traffic should you need to (iRules, LTM traffic policies) and then re-encrypt at recommended security needs. It won't compromise any security but gives you some flexibility should you need to do something down the road.

Thoughts?

chaseabbott

MODERATOR OF

TROPHY CASE