mdex Support>web.direct 2.0

mdex web.direct 2.0

Description of the web.direct functionality of the mCOP 2.0.

1. Introduction

1.1 What can mdex web.direct be used for?

Your requirement:
The HTTP/HTTPS web interface of a device is to be accessed with a browser, where the device is e.g.
  • Cellular router
  • Camera
  • Data logger
  • Control system (e.g. XWEB500).
  • Web server (e.g. IIS, Apache, NGINX ...)
  • etc.

The problem:
Normally, mobile devices in the mobile network can only be reached from the Internet with a publicly accessible IP address. As a rule, however, SIM cards do not receive publicly accessible IP addresses from the providers. Even services such as DynDNS, which solve the problem of accessibility in the fixed network, usually do not work in the mobile network because the SIM cards are generally not assigned any publicly accessible IP addresses.

The solution:
With mdex web.direct access, remote access is possible without a publicly accessible IP address or the creation of an additional VPN tunnel. Here are the advantages of remote access via mdex web.direct:
  • No installation of additional software required.
  • Access with any browser, from any PC or smartphone with Internet access.
  • Multiple devices (routers, terminal devices behind the router) can be accessed via different HTTP/HTTPS ports.
  • The devices are not exposed to any dangers and risks from the Internet thanks to appropriate web.direct security settings, such as
    • Cross-site scripting attacks
    • Portscans
    • search engines
    • and much more.
  • User authentication for secure use of web.direct links.

1.2 How it works

Here you will find the basic functionality of web.direct for accessing the HTTP/HTTPS WebUI of a device (router, terminal device).

Basic requirements:
  • The cellular router must be accessible via a private IP address from the Wireless Logic mdex network, e.g. mdex fixed.IP+ or DevicePro.
  • For remote access to a terminal device (e.g. camera, solar logger, etc.), port forwarding of the required HTTP/HTTPS port to the connected terminal device must have been set up in the cellular router.
  • The web.direct link must have been set up for the required HTTP/HTTPS port and assigned to the Device.
  • The PC or smartphone from which remote access is to be made must have an Internet connection.

Mode of operation:
  1. for remote access to a WebUI, use the URL of the web.direct link in the web browser of your PC or smartphone.
    (The PC or smartphone does not need a VPN connection to mdex, but only access to the Internet).
  2. the browser establishes a connection to the mdex gateway with the URL.
  3. mdex Gateway accepts the request for authentication.
    (Depending on the security option set, authentication takes place either automatically or via additional authentication)
  4. mdex Gateway forwards the request to the private IP address of the SIM card (or mdex fixed.IP+) and thus to the cellular router.
  5. the cellular router forwards the HTTP/HTTPS port set in the web.direct link to the connected terminal device via port forwarding.
  6. the connection to the cellular router's WebUI or the terminal device connected to it is established.

1.3 Supported protocols

Only access to devices with a WebUI (web server) via a specific HTTP/HTTPS port is supported via web.direct, e.g. router configuration interfaces, controllers and control units, cameras, etc.. Please note, however, that cameras whose live images are transmitted via Real Time Streaming Protocol (RTSP) are not supported, but some cameras have a "fallback" mechanism using WebSocket in that case.

Protocol Access via web.direct
HTTP DONE
HTTPS DONE
WebSocket (WS) DONE 1
WebSocket Secure (WSS) DONE 1
Real Time Streaming Protocol (RTSP) choice-no
FTP choice-no
SSH choice-no
SMTP choice-no
Other protocols choice-no
1 Some devices (e.g. certain webcams, data loggers, etc.) require the WebSocket protocol for bidirection communication, which has been supported since web.direct 2.0. When using web.direct 1.0, some content may have been missing from the web display.

1.4 Comparison web.direct web.direct 2.0

Below you will find the differences between the conventional web.direct and the new web.direct 2.0:

function web.direct web.direct 2.0
Direct links: DONE DONE
login links: DONE DONE
URL Paramater: DONE 1 choice-no
WebSocket (WS): choice-no DONE
WebSocket Secure (WSS): choice-no DONE
Link per Device: choice-no DONE 2
Two-factor authentication: choice-no DONE
Optional SSL certificates:
(For terminal devices) 		choice-no DONE
Optional URL path can be set: choice-no DONE 3
Temporary links: choice-no DONE 4

1 The URL can be customised manually for certain protocols/ports and options: (port (-p), protocol (-s), caching (-c)

2 Created web.direct links are generally made available to all accesses of an 'mdex VPN' with the conventional web.direct, even if not every access requires this web.direct access. Since web.direct 2.0, the web.direct links can be specifically assigned to each desired Device.

3 This path is appended to the URL of the web.direct link, e.g. to access certain pages in the terminal device. The path must begin with a slash /, e.g. /motor. The page .../motor is now accessed directly in the terminal device.

4 Temporary web.direct links can now also be created under Link-Timeout (minutes), which are only valid for a certain period of time after creation and are automatically deactivated again after the time period has expired.

2. Setup & configuration (web.direct 2.0)

The web.direct 2.0 is set up in the new mdex Connection Management Portal (mCOP 2.0).
(Login with the same access data (user name & password) as for the conventional mdex Management Portal (mCOP)).

2.1 web.direct templates

The web.direct links are added to the desired Devices via a template. The web.direct templates can be created or customised under web.direct:
  • To add a new template, click on the button Add+
  • To customise an existing template, click on the Edit button of the template.

Template settings

Parameter Description
Activated The template is activated or deactivated.
Create links If activated, these web.direct links are automatically created for new Devices.
Inherit Provision (inheritance) of this template for sub-mandates (partners). Special function for authorised users only!
Priority Priority of the web.direct link for the position in the portal view. Input 0 (top position) to 99 (bottom position)
Created on Date of creation of this template.
Updated on Date on which this template was last updated.

Parameter Description
Name The desired name of the web.direct link must be entered here. This is a required entry which, like the icon, is used for display in the portal.
URL alias The URL alias is part of the web.direct URL. This must be a unique name for alias-based web.direct formats.
alert Changes to the alias lead to short timeouts of max. 5 minutes for technical reasons.
Link display The format for displaying the web.direct URL can be defined here.
  Default The web.direct URL is displayed in the default format:
URL format: [access][-URLAlias][-access hash1][-hash2]
  VPN-based The web.direct URL is displayed as a combination of "VPN name" and "link alias".
URL format: [VPNName][-URLAlias][-AccessHash1][-Hash2]
  Alias-Based The web.direct URL is generated as a combination of access or access alias, followed by the link alias, access hash and link hash.
URL format: [AccessAlias or Name][-URLAlias][-AccessHash1][Hash2]
  Alias only The web.direct URL is displayed as a link alias, device alias or device name (if no alias is configured),
URL format: [URLAlias or Alias or Name]
  Without AccessHash1 The web.direct URL is displayed without a hash. (A possibly generated hash is not taken into account).
URL format: [Device][-URLAlias][-Hash2]
Icon Icon, size and colour of the web.direct link for display in the portal.

1 The hash is automatically generated by the system and cannot be customised.
2 These hash settings are made in the template under Browser mdex Gateway MOVED TO... "Security settings" under Hash (Predefined) and Hash generation.

Browser mdex Gateway

This is where the connection from the web browser (PC, smartphone, tablet, ...) to the mdex gateway is set.
Browser-Gateway.png

Connection settings
Parameter Description
Port / Protocol Required input for how the data is transferred from the browser to the mdex gateway. As a rule, an encrypted HTTPS connection is recommended here, i.e. 443 /HTTPS. (This setting should not be confused with the required port/protocol setting for remote access to the terminal device, which is made under mdex Gateway Terminal device)
The lock symbol in the diagram also indicates whether an unencrypted (insecure) HTTP connection or encrypted (secure) HTTPS connection has been set between the browser and mdex Gateway.
info The realm is usually "mdex". Only if the user uses an 'Mdex Private Network' (MPN) for projects, the ports/protocols of the desired realm must be selected. The respective realm is also displayed in the portal for the respective Device under "Details".
alert Changes to the port/protocol lead to short downtimes of max. 5 minutes for technical reasons.
  443 /HTTPS Recommended for most applications: Encrypted connection between browser and mdex gateway via HTTPS port 443.
  80 /HTTP Unencrypted connection between browser and mdex Gateway via HTTP port 80.
ALERT! This setting should only be used if, for example, there are problems with remote access with the encrypted connection.
Caching Specifies whether and how the browser should cache the content of web pages (adverts, images, etc.) in order to avoid unnecessary data transfers and reduce access times. Since it must also be ensured that the transferred content is not outdated, it is necessary to precisely control caching.
  No caching No website content is cached, but constantly updated. Regular updates result in higher data consumption.
  Default The browser's cache settings are used.
  HTML only Only HTML content is updated, but no scripts or images.
Path (URL) This path is appended to the URL of the web.direct link, e.g. to access certain pages in the terminal device. The path must begin with a slash /, e.g. /motor. The page .../motor is now accessed directly in the terminal device.
Session timeout (minutes) Maximum validity of a web.direct link in minutes. The session is disconnected after the set time has elapsed. This can prevent unwanted data consumption, e.g. if a browser is forgotten to close when accessing live images/videos from a webcam.
Security settings
Parameter Description
Authentication Setting the desired authentication when calling the web.direct link.
alert Changes to the authentication settings lead to short timeouts of max. 5 minutes for technical reasons.
  None (direct link) The web.direct link can be accessed without the user having to authenticate themselves.
ALERT! As the web server of the terminal device can be accessed directly without authentication, the terminal device should be protected with a secure login password and the link should contain a Hash.
  Global password When accessing the web.direct link, the user must authenticate with the specified global password. The global password is set when the link is added. Please note that if the global password in the link is changed, all other links with the "Global password" authentication must also use the new password.
  Link password When calling up the web.direct link, the user must authenticate themselves with the defined link password. The link password is set for the added link and is only valid for this link. Changes to the password therefore do not affect other links.
• No password generation: A password must be set manually.
• Password generation (12 characters): A 12-character password is generated automatically.
• From Device: The default web.direct password is used.
  Portal account (OTP required) When accessing the web.direct link, the user must authenticate themselves with their mCOP portal access data (user name & password) and also the one-time password for two-factor authentication (OTP).
TIP The link usage (authentication) is logged for the respective web.direct link in the "History" window.
ALERT! If the two-factor authentication has not yet been set up in the portal, the links cannot be used!
  Portal Account When accessing the web.direct link, the user must authenticate themselves with their mCOP portal access data (user name & password).
TIP The link usage (authentication) is logged for the respective web.direct link in the "History" window.
Visibility /
Access 		Required entry: Either the visibility in the portal or the use (access) of the web.direct links is set here. This depends on the Authentication set above:

Authentication:
• None (direct link)
• Global password
• Link password
MOVED TO... Visibility (With which role is this link displayed in the portal for users. )

Authentication:
• Portal account (OTP required)
• Portal account
MOVED TO... Access (With which role can the link be used. TIP The link usage (authentication) is logged for the respective web.direct link in the "History" window.)
info Permissions:
As a rule, the preselection of permissions can be left as it is. However, it is also possible to restrict the use of web.direct for certain users based on user groups. Each partner can create user groups and users in the portal. The desired role can be assigned to the user groups. The user group is then assigned to the respective user. One or more roles can be selected for the web.direct links. A user can then use this web.direct link according to the roles granted (according to the user group).
Example:
User A has the roles WebDirectAdmin and WebDirectService.
User B only has the role WebDirectService

If you now set up a link, e.g. with link password and WebDirectAdmin visibility, only user A would see the link. However, user A could forward the link password together with the link to user B, who could then also use this link.

If, on the other hand, you want the Device to be set up selectively, you could create a link with a portal account and WebDirectAdmin access. Only user A would then see the link and be able to use it, as they would then log in to the link with their portal access data.
To the right of the selection menu, the number of users and user groups authorised by the selection made is displayed. By clicking on the respective user icon or user group icon, the authorised users or user groups are displayed.
  Role: Authorisation:
  WebDirect Use of the web.direct links.
  WebDirectAdmin Administration (edit) web.direct links.
  WebDirectTemplateAdmin Administration access for web.direct templates.
  WebPortalAccess Use of the portal (mCOP).
  WebServiceAccess Use of the web.direct links.
  WebDirectAccessAdmin Use of the web.direct links for users as "Administrator".
  WebDirectAccessDealer Use of the web.direct links for users as "Seller".
  WebdirectAccessDistributor Use of the web.direct links for users as "Distributor".
  WebDirectAccessLevel1-3 Use of the web.direct links for users as "Level 1, 2 or 3".
  WebdirectAccessManufacturer Use of the web.direct links for users as "Manufacturer".
  WebDirectAccessService Use of the web.direct links for users as "Service".
  WebDirectAccessUser Enables simple users to use web.direct links
Hash (Predefined) A hash is used to cryptically obfuscate data so that it is no longer displayed in plain text.
A predefined hash can be set here, which is applied to every newly created web.direct link. For security reasons, this is particularly recommended if "None (direct link)" has been set under Authentication.
Hash generation The method for hash generation can be defined here so that a hash is automatically generated from the optional Hash (Predefined) and this method for each newly created web.direct link.
  No hash Only the optional Hash (Predefined) is used.
  Hashes per link The hash is generated based on the web.direct link.
(Each web.direct link has an individual hash.)
  Hashes per Device The hash is generated based on the Device.
(All web.direct links of a Device have the same hash).
  Hashes per Device hash ALERT! This method is obsolete and should no longer be used!
  Hashes per template The hash is generated based on the web.direct template.
(All web.direct links created per template have the same hash.)
  Hashes per VHOST The hash is generated based on the mdex realm.
(All web.direct links of a realm have the same hash).
info The realm is usually "mdex". Only if the user uses an 'Mdex Private Network' (MPN) for projects, the ports/protocols of the desired realm must be selected. The respective realm is also displayed in the portal for the respective Device under "Details".
Link timeout (minutes) Optional: The validity of a web.direct link after creation can be specified here in minutes. This timeout enables the creation of temporary links that can only be used for x minutes after creation and are automatically deactivated after the time has expired. A stopwatch is then also displayed as a symbol in the diagram to indicate this.

mdex Gateway Terminal device

The connection from the mdex gateway (proxy) to the terminal device is set here.
Gateway-Browser.png

Connection settings
Parameter Description
Port Port and protocol (HTTP / HTTPS) for remote access to the terminal device. This port must have been set up as an accessible port in the cellular router or terminal device, e.g. via port forwarding. For security reasons, we recommend setting up remote access in the router or terminal device for an encrypted HTTPS port (e.g. HTTPS port 443). The lock symbol in the diagram also shows whether an unencrypted (insecure) HTTP connection or encrypted (secure) HTTPS connection has been set.
Advanced connection settings
Parameter Description
SSL certificate (PK) Optional: Enter a private client certificate key that the mdex Gateway should use for a secure SSL connection.
SSL certificate Optional: Enter an SSL client certificate that the mdex Gateway should use for a secure SSL connection to the terminal device.