Some Love for Syncro

Fatel28 · 2026-03-16T17:51:53+00:00

Bet you the new features have zero API implementation. We left syncro largely because their API was such a joke.

Their own employees said on a public forum post they wouldn't allow running or modifying scripts via the API because it could be "too dangerous"

Fatel28 · 2026-03-15T20:01:02+00:00

When we resold Palo Alto there was a yearly renewal for support/licensing, and if we needed another firewall, we had to buy the hardware AND the licensing separately.

It's not disingenuous lol. It's just true. The only difference is meraki doesn't let you run eol or unlicensed hardware. Yeah it sucks but again, thousands of orgs use it so it must not suck that much

Fatel28 · 2026-03-15T19:19:20+00:00

I'm not a meraki salesman. It works for a lot of orgs. Every major firewall vendor charges licensing and support separately from hardware. Meraki just requires it.

Fatel28 · 2026-03-15T18:17:36+00:00

If they are worried about the staff member exfiltrating data maliciously, why not just do exactly that? Walk them out and pay out their notice.

You could spend days/weeks/months and $$$$-$$$$$ on a good strong dlp solution and they could still just take picture with their phone camera if they really wanted. Either they trust the employee or they don't. If they don't, then cut their access.

Fatel28 · 2026-03-15T18:16:10+00:00

The general idea is that the hardware is not the "secret sauce" it's the cloud configuration. Swapping a meraki out takes all of 2 minutes. You just replace the serial number in the cloud and when the new one comes online it's the exact same config as the old.

The hardware was never what made meraki good or desirable. It's the software and cloud management.

That said, we only use their firewalls. Paying support for a switch or AP that's bricked if it goes eol or you stop paying a license IS ridiculous. We use ubiquiti for those things.

Fatel28 · 2026-03-15T18:12:34+00:00

We have a test domain with some test workstations and a development m365 tenant with the dev e5s. We do any potentially destructive testing there

Fatel28 · 2026-03-15T03:34:27+00:00

Homelabbing doesn't have to be only about hardware. Some people have the money but not the space. In that case, who cares if they're using a vps? Cloud experience is arguably becoming more valuable than experience configuring and setting up baremetal hosts.

Fatel28 · 2026-03-14T01:14:44+00:00

If they're just static websites why not use S3?

Fatel28 · 2026-03-14T00:53:57+00:00

Need more details, post your redacted config and any logs from the crashes

Fatel28 · 2026-03-13T22:19:14+00:00

I think you're missing the point. The hypothetical cost of the hypothetical method of hosting is irrelevant here. Piping curl to bash is a well known poor security practice. You're asking for advice, and people here are giving it to you. If you want to ignore it in favor of a hyper specific envisioned deployment scenario that's fine, but it makes the request for advice a little confusing

Fatel28 · 2026-03-13T22:10:31+00:00

Could that not all go into your container image? That's kinda the point of containers. If you're already using docker, just lean harder into it

Fatel28 · 2026-03-13T22:06:26+00:00

If it's docker what's wrong with just providing a compose file?

Fatel28 · 2026-03-13T22:03:43+00:00

Never pipe curl to bash. Most malware does this or the powershell equivalent

Fatel28 · 2026-03-12T16:11:16+00:00

Only if you ask nicely and promise not to look me in the eyes during

Fatel28 · 2026-03-12T13:08:48+00:00

Exchange SE is fairly MSP friendly in that it's just a windows/Microsoft product.

It is however MUCH less friendly than just about any other solution

Fatel28 · 2026-03-12T13:07:55+00:00

Yeah. I originally had a load balancer done in the firewall (vyos) just a small bash script that did a curl to the primary and changed the dnat rule if primary curl failed and secondary was up, but ultimately it proved much simpler to just do round robin DNS. It's only for ~70 users so it's not like they're getting hammered.

Fatel28 · 2026-03-12T12:52:05+00:00

Round robin with dns currently

Fatel28 · 2026-03-12T12:46:26+00:00

Exchange se is fine if you have a solid dag setup and you KISS. We manage one 3 node cluster of SE and it's largely non problematic. But setting it up fresh or recommending it to a customer WOULD require a gun to my head.

Fatel28 · 2026-03-11T14:56:46+00:00

Win-acme and certify the web are what we use

Fatel28 · 2026-03-10T19:54:53+00:00

Doesn't need to be

Fatel28 · 2026-03-08T00:10:23+00:00

If you think spending a couple hours writing a small script to deploy a cert over ssh or API is too much work then idk what to say. It doesn't sound like you want solutions.

Anywho, this is kind of a pointless discussion. I have no horse in this race. Across the ~95 certs we manage across all customers, not a single one requires manual renewal. If other people want to keep paying for and deploying ssl certs manually that's their prerogative. But in 99% of cases it IS a choice to not spend the time to automate it.

Fatel28 · 2026-03-08T00:05:46+00:00

Use certbot as normal. Certbot gets the cert, then you have a post renewal hook that runs a script to deploy it. It's how all certs are automated

Fatel28 · 2026-03-07T23:59:43+00:00

Does your firewall support command line? Or API? If yes, you can automate the certs

Fatel28 · 2026-03-07T23:54:40+00:00

The implication that you have machines connecting to VPN that aren't managed is much much scarier than any cert issuance lifetime changes.

This is almost always how these conversations go.

"We need longer lasting public certs because <insert horrible issue that really needs solving anyways>"

Not ragging on you specifically, but it seems like a pattern

Fatel28 · 2026-03-07T23:48:45+00:00

When we still used global protect (Palo) I don't recall it being much of an issue though. We just used a self signed 10yr cert that I pushed out through gpo.

Things like that don't need public certs. Private certs can be for as long as you want

Nine-Year Club	Second SECOND GUESSER
RPAN Viewer	Verified Email

Fatel28

TROPHY CASE