Skip to content
TrackPodcasts
technologySep 21, 202613:23

Tech Bytes: Why Beaver Excavating Tapped Firezone for WireGuard-Powered VPN (Sponsored)

Get every episode summarized

Each time The Everything Feed - All Packet Pushers Pods publishes, we email you a written briefing from the transcript — the topics, who appeared, and any specific claims, with the ad reads skipped.

Email me new episodes

Free for 3 shows. No card needed.

About this episode

Today on the TechBytes podcast, we're talking VPNs. They offer a secure remote access solution built on Wireguard. But instead of just hearing from FireZone, we're going to talk to a customer. He's IT Network and Systems Administrator at Beaver Excavating.From the transcript
Today on the Tech Bytes podcast we talk VPNs. Our sponsor is Firezone, which offers a secure remote access solution built on Wireguard. But instead of just hearing from Firezone, we talk with a customer. Our guest is Daniel Caruso, IT Network and Systems Administrator at Beaver Excavating, a construction firm headquartered in Canton, OH.... Read more »

Hosts & guests

Transcript ready

137 searchable segments. Every word is indexed and playable.

Tech Bytes: Why Beaver Excavating Tapped Firezone for WireGuard-Powered VPN (Sponsored)

The Everything Feed - All Packet Pushers Pods

0:00
13:23

Full transcript

The Everything Feed - All Packet Pushers PodsTech Bytes: Why Beaver Excavating Tapped Firezone for WireGuard-Powered VPN (Sponsored). Machine-transcribed; use the interactive transcript above to jump the player to any line.

Today on the TechBytes podcast, we're talking VPNs. Our sponsor is FireZone. They offer a secure remote access solution built on Wireguard. But instead of just hearing from FireZone, we're going to talk to a customer. Our guest is Daniel Caruso. He's IT Network and Systems Administrator at Beaver Excavating. They are construction firm and boarded in Canton, Ohio. Daniel looked at VPN options to help protect the company's remote desktop infrastructure. He's here to talk about what he looked at, why he chose FireZone, what they did it operations look like, and more. We're also joined by FireZone's co-founder, Jamil Bukir. So Daniel and Jamil, welcome to the podcast. And Daniel, can you just get us started with a quick overview of Beaver Excavating, what the company does? Yes, absolutely. The Beaver companies is a collection of three companies that do different things in different areas. Beaver Excavating is our big one. We do heavy excavating and major like Earth moving projects and stuff across the variety of states. We have Beaver

constructors that does construction based projects. And then we have stone products that does mining and aggregate solutions. So we have a kind of niche in all the different areas. Okay, so and this sounds like then it's a multi-state, multi-site business, lots of offices, lots of probably remote offices and work sites where you need to have connectivity. Absolutely. We have a couple of actual office buildings, but a lot of our work has done out of job trailers that are scattered across the bunch of states. Okay. So then prior to FireZone, how were your employees and workers connecting to remote resources and what kinds of applications and services are they accessing? So most of our employees utilize remote desktop because unfortunately in the construction industry a lot of the construction specific software that we use is from the Stone Age. So a lot of it is on-premise applications that still have to be housed on-premise. Okay.

Makes the lakes cloud migrations a little difficult. Previous to using FireZone, we used a remote desktop gateway which just allowed access to the server open to the internet which was not very secure. So we moved to FireZone to put all that traffic behind encryption. Okay. So before FireZone, I was essentially opening up a web connection or an internet connection, probably doing a username and password at the gateway and then getting access to resources. Correct. Okay. And how are employees connecting? I assume you've got some sort of permanent offices but also lots of work sites where there might not be internet access at the site. So we use three different avenues there. Our actual physical offices obviously they have fiber connections. Our job trailers, most of them utilize the Starlink. We've migrated most of them over

to Starlink and obviously for the guys in the field they just used phone hotspots. But mainly the job trailers were connected via Starlink. Okay. And when you were looking to get a VPN solution, what did you look at anything besides FireZone? We looked at one other option. We looked at OpenVPN Connect just because that was a pretty simple solution to set up. You spin up the server, you create the accounts and people can just connect. It was a very user friendly and it was easy to manage. However, the connection quality wasn't that great. Getting into remote desktop was okay but there was a little bit of lag and we also allow access to file shares and stuff like that over the VPN and that's where OpenVPN was very limiting. We were getting super slow connection speeds even though we have a gigabit connection here. It's just the overhead of the SSL VPN wasn't ideal. Okay. And how did you find FireZone?

Well, when I was starting to get frustrated with OpenVPN, I just started looking at other options and I just happened to know that WireGuard is a superior connection and when I came across FireZone and realized that that's based on a WireGuard connection, I was interested so we gave them a try. Jim, you're here. Can you maybe give us a quick briefing on why you picked WireGuard as the basis for the product? Yeah, so WireGuard is a UDP based protocol. The internal module is really quick as everyone knows but it was also just the most modern protocol at the time. The cryptography was simple to sort of audit and it's, yeah, it was very easy to get started with and most of all, we had some engineering friends out here. I guess this is going back way in the early days of FireZone now but some friends out here in the Bay Area, they had wanted to use WireGuard mainly for the speed

and the latency. That's what we decided to build FireZone with. We're getting. Daniel, can you talk us through deploying the product? What did it take to get up and running? Oh, in the beginning, it was very simple. The process of having the onsite gateways, which we chose to spin up and just Ubuntu VMs because it was really easy to deploy those. It took me all of, I think, maybe 10 minutes. The three commands I think installed the gateway. And then once the gateway was installed, I just had to create a user account and connect. It was very simple. Obviously getting the directory service connected to where we could sync in users from 365 and that kind of stuff took a little bit more and that's actually something that they assisted in getting improved for us because when we first started, there wasn't really a way to filter in

users by group because we have a lot of service accounts and things like that that we didn't want to sync in. It was kind of an all or nothing. But I worked with them to be able to pick a specific group to sync our users in from and they took that, ran with it and were able to deliver something that works fantastic for us. Okay, and these gateways are where the client comes in and the connection terminates or what are the gateways doing? The gateways, they sit on premise and the purpose of the gateway is the direct connection that the clients connect to so you don't have to add, it tunnels directly into the gateway so you don't have to add firewall rules and open ports and all that stuff. So it makes it easy for outside users to get internal access without exposing ports that obviously bad actors could utilize to do bad things. So yeah, the gateway is a lightweight binary. We designed it to be that way so that you could run it on essentially any VM and

you know, even without a hard drive or any sort of persistent store. So and then the natural reversal that Daniel mentioned, yeah, that is something that we wanted to get right. We did build that in-house so it's not from an off off the shelf library. So that is a custom implementation and so from there we're able to optimize it for better performance, power, higher percentage of successful direct connections, etc. And Daniel, what about rolling out the client piece to your end users? What was that experience like? Super easy. We packaged it with Intune as a Win32 app and set it to deploy and it just automatically push to everybody's device. Yeah, okay, that's pretty. So it sounds like you're very much on the Microsoft environment. Absolutely. And the way that they do their Intune apps and the super seeding makes it super easy when a new client gets released. We can just go add that as a super seeding app and it just over writes and upgrades everybody. It makes it super simple. So a fire zone rolls out, changes to the client. It's not a hassle for you to get those upgrades out to the end users.

No, I just have to repackage it and upload it and it will automatically link the super seedings and start updating everybody's device. It takes like a day maybe for it to hit everybody's device, but it's very quick. Okay. So you're now running FireZone day-to-day. Can you talk about the operational experience, the performance experience? So yeah, I used FireZone personally anytime that I work remote, obviously, to access internal stuff. And we periodically put out surveys for people to, because we're always trying to improve everything. And FireZone is just something that people generally don't complain about. The only issue we ever have with it is people assume that they're connected because if their computer goes to sleep or something like that or they close it when they're done with it and they reopen it. Obviously, their connection is dead at that point. Okay. But the GUI will still, when they first open it up, show that they're connected because actually that's being fixed in the next release day. Perfect.

That's really the only issue that we come up with is people think they're connected and they'll put a ticket in saying, I can't get through remote desktop and then we'll just realize that's what happened and just have them close out and reopen FireZone and it reconnects and everything's fantastic. Okay. That's always nice to have the founder on the same podcast with you to let him know what you want. Perfect. Yeah. Did you have to ask? And you mentioned you're not getting complaints from end users and performance seems good because that typically seems like an issue for end users. If the performance is bad, they will let you know. Sure. And generally, most of our users only use it for the remote desktop, especially when they're out of the building. So remote desktop is very lightweight and doesn't require a very large connection. You can get away with a very slow connection for remote desktop to work because the remote desktop client itself is very light. But we do have the occasional users that do transfer documents between the network drives and stuff while they remote over FireZone and that has over time and over the new releases has drastically improved

performance even since we started using the product a year and a half ago. And operationally, do you find yourself spending a lot of time having to write policies or make changes or do troubleshooting? No, not for this. This is probably I'm not not even going to lie the easiest product I've ever rolled out and managed because it really doesn't require any management. And we obviously talked about one thing that you wanted to see change and that sounds like it's happening. Are there other features of capabilities that you'd like to see in the product? The only thing that we've discussed and this is already in motion is a certificate based authentication that we can maybe use to create more of an always on connection that users don't have to manually connect. But that apparently is already in the works. I'm just waiting for something for testing because I think that would be the only thing that we could possibly think of to make it better. Okay. And Jameel, any last words from you about product direction?

Yeah. So that feature that Daniel mentioned, we call that it's actually two parts. The first part is going to be device trust. So that's your standard sort of x.509 at the station. And then we'll throw user auth kind of into that. So it'll be another way that you can authenticate. And then the second piece of that would be device posture. So both of those are coming very soon. Okay. All right. Well, that does wrap up this tech bites episode. If folks want to learn more about FireZone, Jameel, where should they go? Just go to our website, firezone.dev. And then on Twitter or X as it's now called, we are FireZone HQ. FireZone HQ and FireZone.dev. Okay. We'll have those links in the show notes. Daniel, are you online? Are you blogging to have anything you want to send folks to? I don't. But if anybody out there knows anyone that needs heavy excavating, head to bewarexcubating.com. All right. Very good. Well, thank you, Daniel, for being here. Thank you, Jameel and FireZone for being a sponsor.

Sponsors ensure that pack of porcelain can continue to offer high quality, deeply technical content for your professional development for free. Besides tech bites, we've got more than a dozen podcasts for your professional development on networking security IPv6 DevOps, the cloud, and more. We've also got an industry blog. Two weekly newsletters, including our human infrastructure newsletter, a community Slack group if you want to go talk to other networking folks, a YouTube channel, even an IRC group. You can find it all at packupworshut.net, always free, no login required. Here is on Spotify, find us on LinkedIn, and if you would leave us a rating on our podcasts, unless but not least, remember that. Too much networking would never be enough.

More episodes

More from The Everything Feed - All Packet Pushers Pods

View all episodes →