Mikrotik RouterOS 7.x Wireless Dynamic VLAN Assignment - Working Configuration

Overview

This document provides the complete working configuration for dynamic VLAN assignment on Mikrotik RouterOS 7.x wireless access points using RADIUS authentication with EAP-TLS (certificate-based authentication).

Must Have RADIUS Attribute: RouterOS 7.x requires the Mikrotik-Wireless-VLANID RADIUS attribute for wireless dynamic VLAN assignment to work properly.

Authentication Method: EAP-TLS using client certificates with UPN (User Principal Name) in the Subject Alternative Name field.

Network Architecture: Mikrotik acts as a wireless access point only. DHCP services are provided by a remote server, not by the Mikrotik router.

X.509 Certificate User Identification

In modern PKI (Public Key Infrastructure) setups, X.509v3 certificates identify users through specific certificate fields that contain user identity information. The most common methods are:

Important Note: Using the Common Name (CN) or other X.500 subject fields for user identification is considered outdated and deprecated in modern PKI deployments. RFC 5280 and subsequent standards recommend using Subject Alternative Name (SAN) extensions for identity information.

Why CN is Deprecated: - Limited scope: CN can only contain a single identity value - Ambiguity: CN doesn’t specify the type of identity (user, host, service) - Security concerns: CN validation is less strict than SAN validation - Modern standards: RFC 5280, RFC 6125, and RFC 8399 mandate SAN usage - Browser deprecation: Modern browsers no longer trust CN for hostname validation

User Principal Name (UPN)

The User Principal Name (UPN) is the primary method for user identification in enterprise environments. It follows the format username@domain.com and is stored in the certificate’s Subject Alternative Name (SAN) extension.

Certificate Field Location:

Subject Alternative Name:
    otherName: 1.3.6.1.4.1.311.20.2.3 (UPN)
    Email: user@domain.com

Example UPN in Certificate:

X509v3 Subject Alternative Name:
    otherName: 1.3.6.1.4.1.311.20.2.3, SEQUENCE:UTF8String:userA@company.com

Email Address in Subject Alternative Name

Alternatively, user identification can be based on the email address field in the Subject Alternative Name extension.

Certificate Field Location:

Subject Alternative Name:
    Email: user@domain.com  ← Used for user identification

How RADIUS Uses Certificate Identity

During EAP-TLS authentication:

  1. Client presents certificate to the RADIUS server
  2. RADIUS extracts user identity from either:
    • UPN in the SAN extension (preferred)
    • Email address in the SAN extension (fallback)
  3. RADIUS maps the identity to VLAN assignment rules
  4. RADIUS returns VLAN attributes based on the user identity

Example RADIUS Processing:

Certificate UPN: userA@company.com
↓
RADIUS looks up userA@company.com in user database
↓
RADIUS finds VLAN assignment: VLAN 1812
↓
RADIUS returns: Tunnel-Private-Group-Id = 1812

Certificate Requirements for Dynamic VLAN Assignment

For proper dynamic VLAN assignment, client certificates must contain:

  1. Valid UPN or email address in the Subject Alternative Name extension
  2. Proper certificate chain trusted by the RADIUS server
  3. Valid certificate dates (not expired, not future-dated)
  4. Appropriate key usage (digital signature, key encipherment)

Comparison: Old vs Modern Certificate Identity

Old Approach (Deprecated):

Subject: CN=userA, OU=IT, O=Company, C=US
  • Uses Common Name (CN) from subject field
  • Limited to single identity value
  • No type specification
  • Not recommended for modern deployments

Modern Approach (Recommended):

Subject: CN=userA, OU=IT, O=Company, C=US
X509v3 Subject Alternative Name:
    otherName: 1.3.6.1.4.1.311.20.2.3, SEQUENCE:UTF8String:userA@company.com
    Email: userA@company.com
  • Uses Subject Alternative Name (SAN) extension
  • Supports multiple identity types
  • Clear type specification (UPN, email)
  • Compliant with modern PKI standards

Network Architecture Diagram

┌─────────────────────────────────────────────────────────┐
│                    CLIENT A PATH (VLAN 1812)            │
└─────────────────────────────────────────────────────────┘

┌─────────────┐
│  Client A   │
│(EAP-TLS)    │
│userA@...    │
└─────┬───────┘
      │ 802.11
      ▼
┌─────────────┐
│ Mikrotik AP │
│RouterOS 7.x │
│ ┌─────────┐ │ ← RADIUS assigns VLAN 1812
│ │ wlan1/2 │ │   based on userA@domain.com
│ └───┬─────┘ │
│ ┌───▼─────┐ │ ← VLAN filtering enabled
│ │ bridge  │ │   ingress-filtering=no
│ └───┬─────┘ │
└─────┼───────┘
      │ 802.1Q VLAN 1812
      ▼
┌─────────────┐
│  Upstream   │
│Switch/Router│
│(Trunk Port) │
└─────┬───────┘
      │ VLAN 1812
      ▼
┌─────────────┐
│ Remote DHCP │
│Server VLAN  │
│192.168.44.x │
└─────────────┘

┌─────────────────────────────────────────────────────────┐
│                    CLIENT B PATH (VLAN 2000)            │
└─────────────────────────────────────────────────────────┘

┌─────────────┐
│  Client B   │
│(EAP-TLS)    │
│userB@...    │
└─────┬───────┘
      │ 802.11
      ▼
┌─────────────┐
│ Mikrotik AP │
│RouterOS 7.x │
│ ┌─────────┐ │ ← RADIUS assigns VLAN 2000
│ │ wlan1/2 │ │   based on userB@domain.com
│ └───┬─────┘ │
│ ┌───▼─────┐ │ ← VLAN filtering enabled
│ │ bridge  │ │   ingress-filtering=no
│ └───┬─────┘ │
└─────┼───────┘
      │ 802.1Q VLAN 2000
      ▼
┌─────────────┐
│  Upstream   │
│Switch/Router│
│(Trunk Port) │
└─────┬───────┘
      │ VLAN 2000
      ▼
┌─────────────┐
│ Remote DHCP │
│Server VLAN  │
│192.168.55.x │
└─────────────┘

┌─────────────────────────────────────────────────────────┐
│                  SHARED INFRASTRUCTURE                  │
└─────────────────────────────────────────────────────────┘

                ┌─────────────┐
                │ FreeRADIUS  │
                │   Server    │
                │ ┌─────────┐ │ ← Processes certificate UPN
                │ │ EAP-TLS │ │   Returns VLAN attributes
                │ └─────────┘ │
                │ ┌─────────┐ │ ← Adds Mikrotik-Wireless-VLANID
                │ │Post-Auth│ │   attribute for RouterOS 7.x
                │ └─────────┘ │
                └─────────────┘

VLAN Assignment Flow

Client A (userA@domain.com):
1. Client A connects with EAP-TLS certificate
   └── Certificate contains UPN: userA@domain.com

2. Mikrotik sends RADIUS request to FreeRADIUS
   └── Includes certificate UPN: userA@domain.com

3. FreeRADIUS processes UPN and returns:
   └── Tunnel-Type = VLAN
   └── Tunnel-Medium-Type = IEEE-802  
   └── Tunnel-Private-Group-Id = 1812
   └── Mikrotik-Wireless-VLANID = 1812  ← REQUIRED for RouterOS 7.x

4. Mikrotik assigns Client A to VLAN 1812
   └── Client A traffic is tagged with VLAN 1812
   └── Sent to upstream switch via trunk port

5. Upstream switch routes VLAN 1812 traffic
   └── To remote DHCP server for VLAN 1812
   └── Client A gets IP from 192.168.44.x subnet

Client B (userB@domain.com):
1. Client B connects with EAP-TLS certificate
   └── Certificate contains UPN: userB@domain.com

2. Mikrotik sends RADIUS request to FreeRADIUS
   └── Includes certificate UPN: userB@domain.com

3. FreeRADIUS processes UPN and returns:
   └── Tunnel-Type = VLAN
   └── Tunnel-Medium-Type = IEEE-802  
   └── Tunnel-Private-Group-Id = 2000
   └── Mikrotik-Wireless-VLANID = 2000  ← REQUIRED for RouterOS 7.x

4. Mikrotik assigns Client B to VLAN 2000
   └── Client B traffic is tagged with VLAN 2000
   └── Sent to upstream switch via trunk port

5. Upstream switch routes VLAN 2000 traffic
   └── To remote DHCP server for VLAN 2000
   └── Client B gets IP from 192.168.55.x subnet

Prerequisites

  • RouterOS 7.x with classic wireless package (not wifiwave2)
  • FreeRADIUS server configured for EAP-TLS authentication
  • Client certificates properly configured and trusted by RADIUS server
  • RADIUS server must send Mikrotik-Wireless-VLANID attribute
  • Upstream switch/router with VLAN trunking configured
  • Remote DHCP server (not local to Mikrotik) configured for each VLAN subnet

Complete RouterOS Configuration

1. Bridge Configuration

/interface bridge
add admin-mac=AA:BB:CC:DD:EE:FF auto-mac=no comment=defconf name=bridge vlan-filtering=yes ingress-filtering=no

Critical Settings: - vlan-filtering=yes - Enables VLAN filtering - ingress-filtering=no - REQUIRED for dynamic VLAN assignment in RouterOS 7.x - frame-types=admit-all - Allows all frame types

2. VLAN Interfaces

/interface vlan
add interface=bridge name=vlan1812 vlan-id=1812
add interface=bridge name=vlan2000 vlan-id=2000

3. Wireless Security Profile

/interface wireless security-profiles
add authentication-types=wpa2-eap,wpa3-eap comment=EAP-RADIUS-SECURITY disabled=no encryption=tkip,gcmp,gcmp-256 name=EAP-RADIUS-SECURITY

4. Wireless Interfaces

/interface wireless
set [ find default-name=wlan1 ] band=2ghz-b/g/n channel-width=20/40mhz-XX comment=wpa-enterprise-2GHz country=bulgaria disabled=no distance=indoors frequency=auto installation=outdoor mode=ap-bridge security-profile=EAP-RADIUS-SECURITY ssid=wpa-enterprise vlan-mode=use-tag wireless-protocol=802.11 wps-mode=disabled

set [ find default-name=wlan2 ] band=5ghz-a/n/ac channel-width=20/40/80mhz-XXXX comment=wpa-enterprise-5GHz country=bulgaria disabled=no distance=indoors frequency=auto installation=outdoor mode=ap-bridge security-profile=EAP-RADIUS-SECURITY ssid=wpa-enterprise vlan-mode=use-tag wireless-protocol=802.11 wps-mode=disabled

Critical Settings: - vlan-mode=use-tag - Enables dynamic VLAN assignment - security-profile=EAP-RADIUS-SECURITY - Uses EAP-RADIUS authentication

5. Bridge Ports

/interface bridge port
add bridge=bridge comment=defconf interface=ether2
add bridge=bridge comment=wpa-enterprise-2GHz interface=wlan1
add bridge=bridge comment=wpa-enterprise-5GHz interface=wlan2
add bridge=bridge comment=ether1/upstream interface=ether1

6. Bridge VLAN Table

/interface bridge vlan
add bridge=bridge tagged=ether1,bridge,wlan1,wlan2 vlan-ids=1812
add bridge=bridge tagged=ether1,bridge,wlan1,wlan2 vlan-ids=2000

Critical Settings: - Wireless interfaces (wlan1, wlan2) must be tagged (not untagged) - All interfaces that need dynamic VLAN assignment must be in the tagged list

7. RADIUS Configuration

/radius
add address=192.168.0.254 comment=192.168.0.254 service=wireless

Critical Settings: - service=wireless - Required for wireless VLAN assignment - Ensure RADIUS secret matches on both sides

8. Bridge Port Settings (Automatic)

The bridge ports will automatically have these settings: - pvid=1 - Default VLAN ID - frame-types=admit-all - Allows all frame types - ingress-filtering=yes - Per-port ingress filtering

Verification Commands

1. Check Bridge Configuration

/interface bridge print detail

Expected Output:

name="bridge" vlan-filtering=yes ingress-filtering=no frame-types=admit-all

2. Check Bridge VLAN Table

/interface bridge vlan print

Expected Output:

#   BRIDGE  VLAN-IDS  CURRENT-TAGGED         CURRENT-UNTAGGED
1   bridge  1812      bridge,ether1,wlan1,wlan2
2   bridge  2000      bridge,ether1,wlan1,wlan2

3. Check Wireless Registration Table

/interface wireless registration-table print

Expected Output:

Columns: INTERFACE, MAC-ADDRESS, AP, SIGNAL-STRENGTH, TX-RATE, UPTIME
#  INTERFACE  MAC-ADDRESS        AP  SIGNAL-STRENGTH  TX-RATE  UPTIME
0  wlan1      9C:EF:D5:FB:DB:62  no  -27dBm@HT20-0    1Mbps    7s

Important: This command shows connected clients but does NOT display VLAN assignment information. The VLAN assignment happens transparently in the background. Do not expect to see a VLAN-ID column or VLAN information in this output - this is normal behavior for RouterOS 7.x.

4. Check RADIUS Configuration

/radius print

Expected Output:

# SERVICE   ADDRESS        SECRET
0 wireless  192.168.0.254  test123

5. Verify Dynamic VLAN Assignment

Important: The /interface wireless registration-table print command does NOT show VLAN information in RouterOS 7.x. This is normal behavior - do not expect to see VLAN-ID columns or VLAN assignment details in this output.

To verify dynamic VLAN assignment is working:

  1. Check client IP address - Client should get IP from the assigned VLAN subnet (provided by remote DHCP server)
  2. Check upstream switch/router - Verify traffic is tagged with correct VLAN
  3. Monitor FreeRADIUS logs - Confirm Mikrotik-Wireless-VLANID is being sent
  4. Test connectivity - Client should only reach resources in assigned VLAN

Troubleshooting

Issue: Client Gets IP from Wrong VLAN

Symptoms: Client connects successfully but gets IP from default VLAN instead of assigned VLAN.

Solution: Ensure RADIUS is sending Mikrotik-Wireless-VLANID attribute and check upstream switch port trunking configuration.

Issue: DHCP Server Not Responding

Symptoms: Client connects but cannot get an IP address.

Solution: Check upstream switch port trunking and remote DHCP server configuration for the assigned VLAN. Verify the remote DHCP server is listening on the correct VLAN and has available IP addresses.

Issue: Authentication Fails

Symptoms: Client cannot authenticate at all.

Solution: Check RADIUS server connectivity and EAP-TLS certificate configuration. Verify client certificates are valid and trusted by the RADIUS server.

Common Mistakes

  1. Missing ingress-filtering=no on bridge - Required for dynamic VLANs
  2. Wireless interfaces as untagged in bridge VLAN table - Must be tagged
  3. Missing Mikrotik-Wireless-VLANID in RADIUS reply - Required for RouterOS 7.x
  4. Wrong RADIUS service - Must be service=wireless
  5. Wrong vlan-mode - Must be vlan-mode=use-tag

RouterOS Version Compatibility

  • RouterOS 6.x: Works with standard RADIUS attributes only
  • RouterOS 7.x: Requires Mikrotik-Wireless-VLANID attribute
  • wifiwave2 package: Does not support dynamic VLAN assignment

Summary

The key to making wireless dynamic VLAN assignment work in RouterOS 7.x is:

  1. Correct bridge configuration with ingress-filtering=no
  2. Wireless interfaces as tagged in bridge VLAN table
  3. RADIUS sending Mikrotik-Wireless-VLANID attribute
  4. Proper wireless interface configuration with vlan-mode=use-tag

This configuration has been tested and verified to work with RouterOS 7.19.2 and FreeRADIUS with EAP-TLS authentication.

slurmstepd: error: Unable to get current working directory: No such file or directory

This is by far one of the most difficult to solve errors pertaining to Slurm cluster maintenance to comprehend. The AI models cannot understand why it appears, and the analysis of the Slurm codebase is not helpful. The logging verbosity increase is also not particularly beneficial in tracing the source of that error.

This error occurs when the user who is set up as the effective user for Slurm tasks execution is not the one who owns the spool folder used by Slurm on the compute nodes (not the login or management nodes), which is typically the folder /var/spool/slurmd.

By running the following commands, you can see which effective user Slurm uses to configure task execution related to submitted job execution (do not mistake this user with the user who owns the running job processes - the latter are owned by UID and GID of the person who queued the running job).

$ scontrol show config | grep -i SlurmdUser

Therefore, the ownership on /var/spool/slurmd must be the one of SlurmdUser and its primary group (usually root). Otherwise, at each job submission on that node, the user will receive the error:

slurmstepd: error: Unable to get current working directory: No such file or directory

Of course, after fixing the ownership on /var/spool/slurmd, one must restart slurmd on that particular node.

What to do when an HSM token with a large number of stored certificates (or more than one HSM tokens are connected) prevents the SSH agent from using the correct key for SSH authentication on Linux

Many advanced Linux users have been struggling to get rid of one quite annoying situation - the interference between multiple HSM tokens connected to one system. Think about the situation when one token is only needed for SSH authentication and the other token is only needed for S/MIME and web authentication. If each of the tokens contains only one X.509v3 certificate and its private key, things should be fine and in that particular case the command line:

ssh-add -s /usr/lib64/opensc-pkcs11.so

will connect only two of the keys to the SSH agent.

But what if the HSM token hosts four certificates or more than one HSM token is services by the same PKCS#11 library? In that case, during the SSH authentication process, the SSH agent will try the available private keys one after another until the server accepts any of the keys as the proper authentication token. If you have too many keys in the HSM token, the ssh client will be involved in too many authentication attempts, and as a result, the SSH server will terminate the user's authentication. Of course, the latter also depends on the SSH server-side configuration, but the defaults are not in favour of executing multiple key tests.

How to solve this issue?

First, let's start with brining forward the bad news - there exists no definitive resolution in all instances. A workaround is only available. The workaround is not something compex - simply attach the HSM token that contains the key used for SSH authentication before the other HSM tokens, and execute:

ssh-add -s /usr/lib64/opensc-pkcs11.so

Afterwards, you may add as many HSM tokens as you wish to the Linux system. But only the first hinted HSM token will be used to operate with the SSH agent.

Now some details and more information about the process of using HSM tokens for authentication/signing. Read the information below if you are interested in those details.

The X.509v3 certificates get installed inside the HSM protected memory slots along with their private keys. To help the application with the access to that slots, a dedicated PKCS#11 module (library) is needed. In most cases, we employ the PKCS#11 module as a low-level backend in both direction. First, we transfer each X.509v3 certificate along with its private key to the protected memory inside the HMS token, reading that information from PKCS#12 files. Once the keys are stored inside the protected memory of the HSM token, we employ the PKCS#11 module to point the applications to the location of the installed private keys. Note that the applications never obtain direct access to the private keys. Instead, they send some computed hash to the crypto processor inside the HSM token, asking it to sign (encrypt) that hash with a private key with a certain ID (PKCS#12 module communicates those IDs to the application in advance).

Storing multiple keys inside HSM tokens always depends on the token model itself. Some tokens allow the use of multiple slots for signing and authentication, while some do not. The link below shows a good example of tokens that can store multiple X.509v3 certificates in their protected memory:

https://www.cardomatic.de/c/smartcard-hsm

Those brand of tokens can be programmed by using Smart Card Shell 3.

Even though the Yubico PIV tokens are popular, they cannot store multiple X.509v3 certificates and their corresponding private keys. While it is true that those PIV devices come with four slots, each slot has a different purpose, and only one of them can be employed for authentication. Which does not mean Yubico PIV tokens are not as good as the others. They just cannot store more than one certificate/key per dedicated slot. You may try to examine that by running the YubiKey Manager (Ykman) - it shows the four slots and reveals their purpose.

Regardless of the HSM management application, installation of X.509v3 certificates into the HSM tokens does not bring therein the corresponding certificate chains (even if those chains are stored in the original PKCS#12 blocks). The S/MIME client or browser that uses HSM tokens for signing or authentication is responsible for bringing the missing chain certificates into the signing or authentication process. Certificates included in chains are usually installed into special local files accessible and manageable by processing software cryptographic storage. Different programs rely on different file backends for saving and accessing the certificates needed to finish the chains when asked. For instance, Firefox, regardless of the OS environment, always employs Mozilla's NSS Shared DB files for that purpose. While running on Linux, Brave and Chrome for Linux also rely on Mozilla's NSS Shared DB. However, in the event that they are running on Windows, the Windows Certificate Store is utilized as a means of searching for certificates to complete the chain.

If you possess an HSM token that contains more than three X.509v3 certificates installed and accessible through PKCS#11 library, it is not recommended to use that token for SSH authentication. That advice is based on the way the ssh client utilizes the private keys during the authentication process.

What is the good practice to follow when preparing an HSM token, which will be used for SSH authentication only? Store only one certificate, which should be self-signed one. That self-signed X.509v3 certificate must be based on the originally generated SSH key pair stored under the ~/.ssh folder, and should be created and then inserted into the HSM token based on a PKCS#12 file. To create the self-signed certificate, simply run the command line:

openssl req -sha384 -x509 -key ~/.ssh/id_ecdsa -out ~/vesso@ssh-ecdsa.crt -subj "/CN=vesso@ssh-ecdsa" -days 3650

The self-signed certificate will be stored in ~/vesso@ssh-ecdsa.crt. Then compiose the PKCS#12 file:

openssl pkcs12 -export -legacy -key ~/.ssh/id_ecdsa -in ~/vesso@ssh-ecdsa.crt -name "vesso@ssh-ecdsa" -out vesso@ssh-ecdsa.p12

If you want to store that certificate and its private key onto your HSM key, use the appropriate device manager to import the content of the PKCS#12 file into the protected memory of the HSM token. If that is one of the HSM tokens mentioned above, adopt Smart Card Shell 3 for the import. In case you would like to use Yubico PIV token, then rely on the Yukman.

How to fix a problem with running the latest AppImage version of YubiKey Manager on Rocky Linux 9.4

Yubico provides an easy to run YubiKey Manager (Ykman), packed as an AppImage. One can download that image by following the download URL provided at:

https://www.yubico.com/support/download/yubikey-manager/

To obtain and use Ykman as an AppImage, open a terminal window, use wget to download the AppImage file, and then set the right permissions (chmod) for executing it:

wget https://developers.yubico.com/yubikey-manager-qt/Releases/yubikey-manager-qt-latest-linux.AppImage
chmod 755 yubikey-manager-qt-latest-linux.AppImage
./yubikey-manager-qt-latest-linux.AppImage

It may sound easy and convenient. However, if you try running Ykman as an AppImage on Rocky Linux 9.4, the app won't start. This is due to the latest implemented SELinux policy.

To prevent that failure from happening, create a new file called ykman.avc and store inside the following content (as a single line):

type=AVC msg=audit(1717919286.134:498): avc:  denied  { execmod } for  pid=17549 comm="ykman-gui" path=2F6D656D66643A4A4954436F64653A5174516D6C202864656C6574656429 dev="tmpfs" ino=161080 scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file permissive=0

Afterwards, compile a new module:

sudo audit2allow -M ykman < ykman.avc

and install it:

semodule -i ykman.pp

That should solve the issue.

What to do if Smart Card Shell (scsh) cannot detect HSM tokens connected to RHEL9 or Rocky 9 installation

The HSM management through scsh on RHEL9 (incl Rocky 9) may pose a challenge due to an issue with the manner in which that Linux distribution installs PCSC Lite components. Consequently, neither the scsh command line tool nor scsh3gui are capable of recognizing the HSM tokens that have already been connected to the system.

The problem is caused by the set of libraries that are installed by default when smart card support is enabled on the distribution through the package system. That support implies the installation of libpcsclite.so.1 instead of libpcsclite.so. To make scsh recognize the connected HSM tokens, one should find a way to bring libpcsclite.so into the system, which is required by Java OpenJDK for successful execution of scsh classes.

Now, in greater details. By enabling smart card support, the package management system installs those two packages:

pcsc-lite
pcsc-lite-libs

as well as their dependencies. Here pcsc-lite-libs only provides:

/usr/lib64/libpcsclite.so.1

None of the above provides:

/usr/lib64/libpcsclite.so

At this juncture, it is advised to refrain from creating manually libpcsclite.so as a symlink to libpcsclite.so.1, as it may result in interference with the package system. There is a much more proper way to bring libpcsclite.so to the system:

dnf install pcsc-lite-devel

Installing pcsc-lite-devel just creates the necessary symlink and registers it in the RPM database.

Vivacom's Mobix dual-stack (IPv4/IPv6) LTE router configuration for LTE routers running OpenWRT

This document demonstrates the configuration of a dual-stack (IPv4/IPv6) subscription to Viacom service "Mobix" (Internet home access over LTE) on OpenWRT LTE routers.

Vivacom, which is valid for any other LTE operator in the vicinity, provides its customers outside the big cities with 4G/LTE home routers. They are not without their disadvantages. The biggest disadvantage is the low speed you get if your location is not well covered. Even mounting an external antenna to the router doesn't make the speed go up if the device resides inside a building. Furthermore, the RTT average fluctuates a lot, resulting in a dreadful SSH shell-typing encounter.

The only viable approach to resolving the issues associated with the RTT deviation is to procure a superior 4G/LTE router running OpenWRT that is capable of supporting MIMO. You might also want to get an external MIMO antenna to improve the router's reception and transmission capabilities.

Another benefit of using OpenWRT-based 4G/LTE routers is the possibility of obtaining an IPv6 /64 Internet connectivity for the devices connected to your home network. Vivacom operates a dual-stack IPv4/IPv6 network. It assigns to the external network interface of the customer's LTE router one public IPv4 address and one IPv6 address if the router supports IPv6 subscription. Furthermore, that router is assigned a /64 IPv6 address segment for addressing devices within the internal (home) network. That's a significant step forward in implementing IPv6 at the end-user level. Sadly, most of the routers given to customers are incapable of performing IPv6 LTE subscriptions. The latter is yet another reason to buy and adopt modern OpenWRT LTE routers at home.

The LTE OpenWRT routers provided by Teltonika are very robust and durable devices. I like those devices because they are easy to manage and do not heat up. What I have at home is a pair of RUT-series LTE routers:

RUT241

RUT901

Below, I'm showing how to set up RUT241, but the same procedure works for RUT901. Both have what you need to work with MIMO and IPv6 LTE subscriptions. Note that they are equipped with MIMO antennas by default. If you have a place to mount the antennas, you may want to consider using outdoor LTE antennas to increase signal reception and transmission efficiency. I use this one:

MIMO 4G/5G Log Periodic Antenna

Insert the SIM card into the router and switch it on. Use a browser to connect to the router and set it up initially (if the setup is not done already). Go to "Network" > "Mobile" and set there manually B3 frequency band (that band provides better coverage and higher speed):

Then go to "Status" > "Overview" and set there a profile that uses the "mobix-static" APN (it provides the static IPv4/IPv6 address subscription). In the web interface, go to "Network" > "WAN" and edit the settings for the network interface mob1s1a1. Select "Custom" from the "APN" dropdown menu, then type "mobix-static" into the "Custom APN" text box. Press the "SAVE & APPLY" button to save and apply those settings:

At that moment, the LTE router will re-subscribe to Vivacom's network and obtain its static public IPv4 address. No IPv6 address will be configured at this time. To configure the IPv6 subscription, you need to use the command-line interface for editing the dual-stack subscription settings (the web interface does not offer a menu for managing the IPv6 subscription). Use an SSH client to connect to the router. Then open the file /etc/config/networks and find the entry section for the interface mob1s1a1. Be sure the "pdtptype" is set to "ipv4v6". That's a must-have for requesting a dual-platform subscription. It is recommended that the option 'ipv6' be set to 1.

  config interface 'mob1s1a1'
        option proto 'wwan'
        option modem '1-1'
        option metric '2'
        option sim '1'
        option pdp '1'
        option username 'vivacom'
        option password 'vivacom'
        option auth 'pap'
        option pdptype 'ipv4v6'
        option force_apn '-1'
        option auto_apn '0'
        option apn 'mobix-static'
        option delegate '1'
        option force_link '0'
        option dhcpv6 '0'
        option method 'nat'
        option ipv6 '1'
  

Then save and close the file, and execute:

ifup mob1s1a1

Wait for 10–15 seconds. Afterwards, you will be able to see information about the success of the requested dual-stack configuration on mob1s1a1. Simply execute:

ip addr show

and find there in the output information about the addresses configured on the mobile network interface (in my case, that interface has the name wwan0).

11: wwan0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
    link/none
    inet 95.3.65.17/32 brd 255.255.255.255 scope global wwan0
       valid_lft forever preferred_lft forever
    inet6 2a01:5a8:1a4:14c:6c78:f01f:daf3:4150/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::c965:519:7205:f216/64 scope link stable-privacy
       valid_lft forever preferred_lft forever
12: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:1e:42:4f:74:72 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.1/24 brd 192.168.1.255 scope global br-lan
       valid_lft forever preferred_lft forever
    inet6 2a01:5a8:1a4:fff::1/64 scope global noprefixroute
       valid_lft forever preferred_lft forever
    inet6 fdb5:99f7:fdfa::1/60 scope global noprefixroute
       valid_lft forever preferred_lft forever
    inet6 fe80::21e:42ff:fe4f:7472/64 scope link
       valid_lft forever preferred_lft forever

Pay attention to the configuration shown. The public IPv4 is assigned to the interface wwan0. The same interface has a dynamically generated IPv6 address that isn't fixed (static). In fact, you get a static IPv6 subnet—the one that is configured on the LAN interface. Which means that your static IPv6 address on the LTE router is 2a01:5a8:1a4:fff::1/64 (assigned to br-lan), not 2a01:5a8:1a4:14c:6c78:f01f:daf3:4150 (assigned to wwan0).

What's left is to enable DHCP6 and router advertising in the home network (connect to the br-lan interface of the LTE router). That is necessary if the device connected to the home network should be given an IPv6 address and an IPv6 default route. Open the file /etc/config/dhcp and add to the "config dhcp lan" section the following set of instructions:

  
    option dhcpv6 server
    option ra server
    option ra_flags 'managed-config other-config'
  

Finally, restart the router and enjoy the dual-stack connectivity.


Using OpenSSL "ec" tool to encrypt the just-generated EC keys with ciphers stronger than 3DES

It is considered prudent to store the EC keys securely, to prevent OpenSSL library and tools from writing the keys unencrypted to the local file system. While it is possible to encrypt the generated key afterwards, it is considered important to prevent the key from appearing in its unencrypted form in any file. Such disclosure of the key will definitely occur if openssl ecparam -genkey is used with -out (that implies storing the unencrypted key in a file). The root cause of the issue is due to the inability to enable password protection when openssl ecparam -genkey is invoked to generate EC keys. That inability is what makes necessary the subsequent use of the "ec" tool to encrypt the generated EC keys. On the other side, the OpenSSL man pages that come with the OpenSSL installation on Red Hat Enterprise Linux 8/9 (and its derivatives), do not mention the use of a cipher other than 3DES with "ec". This ambiguity causes considerable confusion. This short post explains how to use strong AES encryption to protect the just-generated EC key with a password.

Generate an EC key, but instead of storing the result in a file, send it to the "ec" tool. Even if both the help information and man page of "ec" do not provide any information on how to request AES encryption, specify the corresponding AES cipher in the command line:

openssl ecparam -genkey -name secp384r1 | openssl ec -aes-256-cbc -out my.key

But can we employ a cipher different than 3DES and aes-256-cbc? You can answer that question by checking what is supported by your OpenSSL installation. To do that just type:

openssl --help

and analyze the output. For example, the following ciphers are supported on Red Hat Enterprise Linux 9:

aes-128-cbc       aes-128-ecb       aes-192-cbc       aes-192-ecb       
aes-256-cbc       aes-256-ecb       aria-128-cbc      aria-128-cfb      
aria-128-cfb1     aria-128-cfb8     aria-128-ctr      aria-128-ecb      
aria-128-ofb      aria-192-cbc      aria-192-cfb      aria-192-cfb1     
aria-192-cfb8     aria-192-ctr      aria-192-ecb      aria-192-ofb      
aria-256-cbc      aria-256-cfb      aria-256-cfb1     aria-256-cfb8     
aria-256-ctr      aria-256-ecb      aria-256-ofb      base64            
bf                bf-cbc            bf-cfb            bf-ecb            
bf-ofb            camellia-128-cbc  camellia-128-ecb  camellia-192-cbc  
camellia-192-ecb  camellia-256-cbc  camellia-256-ecb  cast              
cast-cbc          cast5-cbc         cast5-cfb         cast5-ecb         
cast5-ofb         des               des-cbc           des-cfb           
des-ecb           des-ede           des-ede-cbc       des-ede-cfb       
des-ede-ofb       des-ede3          des-ede3-cbc      des-ede3-cfb      
des-ede3-ofb      des-ofb           des3              desx              
idea              idea-cbc          idea-cfb          idea-ecb          
idea-ofb          rc2               rc2-40-cbc        rc2-64-cbc        
rc2-cbc           rc2-cfb           rc2-ecb           rc2-ofb           
rc4               rc4-40            rc5               rc5-cbc           
rc5-cfb           rc5-ecb           rc5-ofb           seed              
seed-cbc          seed-cfb          seed-ecb          seed-ofb          
zlib  

If you're moving a file with an encrypted EC key from one system to another, make sure that the OpenSSL installation there supports the cipher you used. Otherwise, the EC key won't be decrypted.


Creative Commons - Attribution 2.5 Generic. Powered by Blogger.

Implementing LUKS Encryption on Software RAID Arrays with LVM2 Management

A comprehensive guide to partition-level encryption for maximum security ...

Search This Blog

Translate