<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
For lack of any other guidance, this sounds good to me. I'm
definitely not a security professional though, so it could be
awful. No idea how it'll work with phones in the field yet.<br>
<br>
I think we should tag both the public + mgmt networks, since an
untagged network can always have tags inserted by users and gain
access to the mgmt VLAN?<br>
<br>
I propose we use 10.44.0.0/16 for the mgmt space, with a VLAN number
of 1044. Each site can take a /24 from that /16.<br>
<br>
For sectors that carry public untagged, that must also for some
reason carry mgmt, maybe they can macsec? I dunno if we can do that
on RouterOS.<br>
<br>
Also no idea how the VRF and any route leaking are gonna work.
They've been problematic on VyOS, and always tricky on RouterOS, but
maybe that's just me holding them wrong.<br>
<br>
This may also be a good time to flip the cell sites to mostly bridge
modems? Our R1 CPUs aren't very strong though, so that may be a
blocker.<br>
<br>
I'm about to install a switch at SnoDEM that should definitely not
be on the Internet, so I guess the mgmt VLAN will start there.<br>
<br>
--Bart<br>
<br>
<div class="moz-cite-prefix">On 2/15/2023 11:33 PM, Doug Kingston
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAGPaoUtf7W9KXQKwOQD3N+5v5K+pP54CvRuA7uxhjaZrcAWbWQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div class="gmail_default" style="font-size:small">I am guessing
that we will want some form of overlay admin network
potentially using VLANS and VPN access of some form?</div>
<div class="gmail_default" style="font-size:small">I have been
working recently to get OpenVPN up and running with various
client platforms to Mikrotik routers with some success.</div>
<div class="gmail_default" style="font-size:small"><br>
</div>
<div class="gmail_default" style="font-size:small">-Doug-</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sun, Feb 12, 2023 at 4:03
PM Bart Kus <<a href="mailto:me@bartk.us"
moz-do-not-send="true" class="moz-txt-link-freetext">me@bartk.us</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
I'd like to kick off discussion about HamWAN security with a
relatively <br>
high level problem statement.<br>
<br>
We need to limit access to our control infrastructure
(routers, <br>
switches, modems, hypervisors, iLOs, etc) while still allowing
easy <br>
reliable access for amateur administrators to control that <br>
infrastructure. We also need to support the case of a person
on a tower <br>
with a cell phone being able to easily login it to a modem to
get <br>
real-time signal readings for dish alignment.<br>
<br>
The current network is mostly a single flat OSPF routing
domain. We <br>
have a couple peering points, and some IPsec tunnels. Our
routers are <br>
mostly RouterOS flavor, which supports a pretty wide set of <br>
capabilities. We may want to look at switching the edge
routers to VyOS <br>
though.<br>
<br>
What general high level design would be useful in keeping
access easy, <br>
while moving the control points out of public reach?<br>
<br>
--Bart<br>
<br>
_______________________________________________<br>
SecOps mailing list<br>
<a href="mailto:SecOps@hamwan.org" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">SecOps@hamwan.org</a><br>
<a href="http://mail01.fmt.hamwan.net/mailman/listinfo/secops"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">http://mail01.fmt.hamwan.net/mailman/listinfo/secops</a><br>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>