<div dir="ltr"><div class="gmail_default" style="font-size:small">There claims to be an OpenVPN client for Android available from the Play Store.</div><div class="gmail_default" style="font-size:small"><a href="https://play.google.com/store/apps/details?id=de.blinkt.openvpn&hl=en_US&gl=US">https://play.google.com/store/apps/details?id=de.blinkt.openvpn&hl=en_US&gl=US</a><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I have not tried this but can check it out to confirm viability and process.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">There also appears to be iOS support.</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 Mon, Feb 20, 2023 at 9:52 AM Bart Kus <<a href="mailto:me@bartk.us">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">
  
    
  
  <div>
    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 <a href="http://10.44.0.0/16" target="_blank">10.44.0.0/16</a> 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>On 2/15/2023 11:33 PM, Doug Kingston
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      <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" target="_blank">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">SecOps@hamwan.org</a><br>
          <a href="http://mail01.fmt.hamwan.net/mailman/listinfo/secops" rel="noreferrer" target="_blank">http://mail01.fmt.hamwan.net/mailman/listinfo/secops</a><br>
        </blockquote>
      </div>
    </blockquote>
    <br>
  </div>

</blockquote></div>