<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Because a lot of it, for us anyway, is not within an organization.
It's inter-organization (as we provide DHCP and DNS for clients).
Why would one add VPN endpoints that will act as another point of
failure? An additional point of complexity? an additional piece of
equipment to maintain, update, power, etc? If one decided to update
their VPN endpoint or switch to another vendor, would they require
that every client replace their VPN at the same time? Would one,
instead, stick themselves with the burden of purchasing, managing,
and maintaining hundreds of remote VPN endpoints in locations they
may have no access to?<br>
<br>
If you have a VPN in place already for another application, sure.
Use it. But for those who don't need a VPN, why would one choose to
take on the above burdens for the sole purpose of obfuscating the
contents of DHCP packets from the eyes of tier1/2 carriers? One's
MAC address and IP address are not exactly the most sensitive info.<br>
<br>
<div class="moz-signature"><br>
</div>
<div class="moz-cite-prefix">On 6/9/2022 11:26 AM, Bruce Wainer
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAPEXuizvJORijYC+N+ro7x8BzPBmovBQdRrVh31gFKjuSbqVBQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
I agree with Grant. Just like we’re run centralized DHCP and DNS
for a decade, we’ve run DMVPN and are now moving to SDWAN. If your
organization isn’t large enough for those types of automatic
VPN/tunnel building, manually creating VPNs back to your central
datacenter is probably something you’re going to do anyway for
internal server access, so why not send the DHCP through that as
well?<br>
<br>
On Thursday, June 9, 2022, Grant Taylor <<a
href="mailto:gtaylor@tnetconsulting.net" moz-do-not-send="true"
class="moz-txt-link-freetext">gtaylor@tnetconsulting.net</a>>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">On 6/9/22 7:19
AM, Blake Hudson wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
We've used DHCP relay/helper across WAN connections for over a
decade without issue. Sometimes it doesn't make sense to have
a DHCP (or DNS or RADIUS) server on-site.<br>
<br>
As others have stated, unicast DHCP is no different than any
other unicast packet.<br>
</blockquote>
<br>
I understand all the above.<br>
<br>
What I'm not yet sure of is why you would not run such
site-to-site traffic through a VPN.<br>
<br>
It seems to me like DHCP, DNS, RADIUS, etc. would benefit from
staying within the control of a common administrative entity.
As such, it seems logical to use a VPN between two distant
pockets of said administrative entity.<br>
<br>
I'm just trying to understand what / why others are thinking and
learn therefrom.<br>
<br>
<br>
</blockquote>
</blockquote>
<br>
</body>
</html>