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">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>
<br>
-- <br>
Grant. . . .<br>
unix || die<br>
<br>
</blockquote><br><br>-- <br>Bruce Wainer<br>