Hi Jeremy,
Mostly been using this setup for SNMP and remote management of devices,
however as a test I've seend Netflix streamed from the US over a SSTP
tunnel without any problems.
The biggest limitation will be the 3G, as it's dependant on available
bandwidth in the area.
Darren.
On 7/09/2017 4:35 AM, Jeremy Hall wrote:
> Thanks, Darren - very useful!
>
> Any comments or observations on real-world performance of SSTP tunnels
> (TCP over TCP) over 3G/LTE connections?
>
> Cheers
> Jeremy
>
> On Tue, Sep 5, 2017 at 10:10 PM, Darren Clissold <darren(a)duxtel.com
> <mailto:darren@duxtel.com>> wrote:
>
> Remote router connects to VPN router by SSTP, and route a subnet
> down the connection for the LAN.
>
> Remote router dialing in has the advantage in that you can have
> more than one gateway (can have a DHCP on a eth and 3G/4G just
> adjust distances) and it will connect on either and still have the
> same addressing, no need to worry about the remote sites outside
> IP either as you never connect to it directly.
> Can use the router secrets table or a Radius server for greater
> control (extra routes).
>
> Darren
>
>
> On 27/08/2017 8:33 AM, Jeremy Hall wrote:
>
> Hi all,
>
> I have a small project coming up that involves a m2m network
> for remote
> monitoring and control of distrubuted equipment, and I am
> interested in
> hearing about the designs and architectures that folks here
> may be using
> for this type of application.
>
> The project will involve multiple remote sites, all with
> similar or
> identical industrial equipment (PLCs, IP cameras etc) and most
> likely
> connected to a dedicated 3G/4G service via a Mikrotik gateway. The
> equipment on the remote sites will need to be accessible over
> the network
> by a server (to collect data from equipment), a few
> individuals (for
> maintenance purposes) and by end customers (who should only be
> able to
> access devices on their own site/s, and not the whole network).
>
> I have previously implemented a similar project where these
> remote sites
> (RB912 or similar) would run a VPN client and establish a PPTP
> tunnel back
> to a head office router (RB1100AH). The connection was over a
> 3G service or
> where permitting, would be plugged right in to the customer's
> own network
> (using NAT and DHCP-client) and get internet access. Per a helpful
> suggestion from Mike, each remote network had the same subnet,
> which
> allowed for much simpler 'copy and paste' site setups, and the
> router/tunnel was allocated a single static address
> (representing a single
> site) on the VPN network. DST-NAT rules on the remote router
> were used to
> gain access to specific equipment on the remote network using
> arbitary
> ports.
>
> This worked well enough, but had a couple of disadvantages;
> mainly that the
> DST-NAT port forwarding could create issues and confusion, but
> also that
> the whole lot was dependent on the office router/network being
> available,
> PPTP could not really be claimed to be 'secure' and customers
> could not
> access their equipment unless we gave their remote site router
> a public IP
> address and opened up access that way.
>
> Facing a similar project now, I'm curious about other
> implementations and
> approaches, and how other folks might have built out solutions
> around
> similar requirements.
>
> For instance, I'm currently dreaming of a solution along the
> lines of a VPN
> server running on a cloud provider, also running a reverse
> proxy (nginx)
> open to the internet, such that authenticated (?) customers
> can create TCP
> connections to a device using a hostname like '
> device.site.customer.mycompany.com
> <http://device.site.customer.mycompany.com>' or
> 'customer.mycompany.com/device
> <http://customer.mycompany.com/device>' (via
> proxy_pass and url rewrite directives in nginx). Each remote
> site has a
> small unique subnet (perhaps a /26) so every device is individualy
> addressable. Maintenance staff can connect to the VPN server
> from wherever
> and have access to the full network.
>
> If anyone has anything to contribute regarding your own set
> up, that would
> be most helpful!
>
> Cheers
> - Jeremy
> _______________________________________________
> Public mailing list
> Public(a)talk.mikrotik.com.au <mailto:Public@talk.mikrotik.com.au>
> http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
> <http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au>
>
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus <https://www.avast.com/antivirus>
>
>