DEV Community: Rev

Setting Up an L2TP/IPsec Remote Access VPN on EdgeRouter X

Rev — Tue, 28 Apr 2026 15:46:56 +0000

Introduction

In the previous article, Running an AWS Lambda + Route 53 DDNS Client on EdgeRouter X, I built a system that periodically runs a DDNS client on the EdgeRouter X to keep a Route 53 DNS record in sync with the global IP address assigned to its WAN interface. This made it possible to associate an FQDN with the dynamically changing global IP address. In this article, I use that setup to connect to the EdgeRouter X via remote access VPN.

References

Test Environment

Tested on EdgeRouter X (ER-X) firmware 3.0.1.

Network Topology

The diagram below is a simplified view of the configuration that connects Site A and Site B via VPN.

graph LR
    subgraph SiteA["Site A (192.168.10.0/24)"]
        PC[PC] --- L2SWA[L2 Switch] --- RouterA[Router]
    end

    subgraph SiteB["Site B (192.168.1.0/24)"]
        ERX[EdgeRouter X] --- L2SW[L2 Switch]
        L2SW --- NAS[NAS]
        L2SW --- RPI[Raspberry Pi]
        L2SW --- AP[Wireless AP]
        AP -.-|Wireless| IoT1[IoT Device 1]
        AP -.-|Wireless| IoT2[IoT Device 2]
        AP -.-|Wireless| IoT3[IoT Device 3]
    end

    RouterA ===|VPN| ERX

Configuring L2TP/IPsec

I configured L2TP/IPsec by following EdgeRouter X – 6. リモートアクセス VPN (L2TP).

Open the CLI window from the EdgeRouter X GUI, or access the router via SSH.

  _____    _
 | ____|__| | __ _  ___          (c) 2010-2023
 |  _| / _  |/ _  |/ _ \         Ubiquiti Inc.
 | |__| (_| | (_| |  __/
 |_____\__._|\__. |\___|         https://www.ui.com
             |___/

Welcome to EdgeOS

By logging in, accessing, or using the Ubiquiti product, you
acknowledge that you have read and understood the Ubiquiti
License Agreement (available in the Web UI at, by default,
http://192.168.1.1) and agree to be bound by its terms.

Enter configuration mode:

configure

In configuration mode, run the following commands to configure L2TP/IPsec:

## Basic IPsec configuration
set vpn ipsec ipsec-interfaces interface eth0
set vpn ipsec nat-networks allowed-network 0.0.0.0/0
set vpn ipsec nat-traversal enable
set vpn ipsec auto-firewall-nat-exclude enable

## Specify that the L2TP WAN-side IP address is assigned via DHCP
set vpn l2tp remote-access dhcp-interface eth0

## Specify the IP address range assigned to L2TP clients
set vpn l2tp remote-access client-ip-pool start 192.168.1.100
set vpn l2tp remote-access client-ip-pool stop 192.168.1.200

## Set the L2TP "secret"
## Replace YOUR_SECRET with any password of your choice
set vpn l2tp remote-access ipsec-settings authentication mode pre-shared-secret
set vpn l2tp remote-access ipsec-settings authentication pre-shared-secret YOUR_SECRET
set vpn l2tp remote-access ipsec-settings ike-lifetime 3600

## Set L2TP client authentication to local
set vpn l2tp remote-access authentication mode local

## Set the L2TP client username and password
## Replace YOUR_USERNAME and YOUR_PASSWORD with your values
set vpn l2tp remote-access authentication local-users username YOUR_USERNAME password YOUR_PASSWORD

## Set the L2TP MTU conservatively
set vpn l2tp remote-access mtu 1280

## Set the DNS used by L2TP clients to the router itself and Google DNS
set vpn l2tp remote-access dns-servers server-1 192.168.1.1
set vpn l2tp remote-access dns-servers server-2 8.8.8.8

## Enable DNS forwarding on the router so that L2TP clients can use the router's DNS
set service dns forwarding listen-on lo

commit
save

Firewall Configuration on the WAN-Side Interface

Next, configure the firewall so that L2TP/IPsec connections from the WAN side can reach the EdgeRouter X. This is also based on the sites listed in the References section.

Log in to the EdgeRouter X GUI as an administrator and open the firewall settings. Click the Firewall/NAT icon in the left-side menu.

Click the Firewall Policies tab → Actions for WAN_LOCAL → Edit Ruleset.

Click Add New Rule. (The screenshot below shows the state after the rules described below have already been added.)

Click the Basic tab. Enter any name in Description. Here, I use Allow L2TP. For Action, select Accept, and for Protocol, select UDP.

Then click the Destination tab and enter 500,1701,4500 in Port. Finally, click Save.

Next, click Add New Rule again.

Click the Basic tab. Enter any name in Description. Here, I use Allow ESP. For Action, select Accept. For Protocol, select Choose a protocol by name, and choose esp from the dropdown. Finally, click Save.

Move the two newly added rules so they sit between the existing Allow established/related rule and the Drop invalid state rule. You can drag and drop each rule by hovering over it.

Configuring the VPN Client on Windows 11

My Windows 11 system is set to English, so the menus and buttons appear in English. The screen layout and button positions are the same in the Japanese version, so substitute as needed.

In the Settings app, click Network & Internet → VPN → Add VPN.

Fill in each field by referring to the table below.

Field	Value
VPN Type	`L2TP/IPsec with pre-shared key`
Type of sign-in info	`Username and password`
Connection name	Any name
Server name or address	The FQDN configured via DDNS
Pre-shared key	The `YOUR_SECRET` set in the L2TP/IPsec configuration
Username	The `YOUR_USERNAME` set in the L2TP/IPsec configuration
Password	The `YOUR_PASSWORD` set in the L2TP/IPsec configuration

In the VPN connection you just created, click Advanced options.

Click Edit next to More VPN properties.

Click the Security tab, select Allow these protocols, and check Microsoft CHAP Version 2 (MS-CHAP v2).

Click the Networking tab, select Internet Protocol Version 4 (TCP/IPv4), and click Properties.

On the General tab, click Advanced.

On the IP Settings tab, uncheck Use default gateway on remote network.

Verifying the Connection

Click Connect.

When the connection succeeds, the connection details are displayed as follows.

If you can reach network devices behind the VPN, such as a NAS, the connection is working. Internet traffic is routed through the WAN side of the EdgeRouter X. You can also access the LAN-side IP address of the EdgeRouter X from the VPN client to check the status of the remote site.

Conclusion

In this article, I covered how to connect to an EdgeRouter X via remote access VPN, specifically:

L2TP/IPsec configuration on the EdgeRouter X
Firewall configuration on the WAN-side interface
VPN client configuration on Windows 11

The Windows 11 VPN client setup was a bit involved. The VPN properties span several screens, and a few options are not particularly intuitive.

For EdgeRouter X configuration in general, the EdgeRouter X がすごい series is a great reference. It contains many practical configuration examples, so I recommend it as a reference.

By combining the previous article, Running an AWS Lambda + Route 53 DDNS Client on EdgeRouter X, with the configuration described here, you can connect to your EdgeRouter X via remote access VPN. I hope this article is helpful.

Translation notes

A few stylistic decisions I made to match your previous dev.to post:

Headings: Used ## Introduction, ## References, ## Test Environment, and ## Conclusion, identical to the prior post.
Voice: First-person ("I built", "I use") for narrative sections and imperative ("Click", "Run") for procedural steps, matching your earlier article.
Terminology: Kept "shared secret", "Lambda function URL", "FQDN", "WAN side" consistent with the previous translation. "拠点 A / 拠点 B" → "Site A / Site B" to match common networking phrasing.
References: Listed as bullet points with <>-wrapped URLs, the same format as before.
Title: Used Setting Up an L2TP/IPsec Remote Access VPN on EdgeRouter X to mirror the gerund + "on EdgeRouter X" style of the prior title (Running an AWS Lambda + Route 53 DDNS Client on EdgeRouter X). If you prefer something closer to the literal Japanese, Connecting to EdgeRouter X via Remote Access VPN also works.
Image links: Left the Qiita-hosted image URLs intact. They are publicly accessible from S3, so they should render on dev.to as-is. If you want to host them on dev.to instead, you'll need to re-upload via the dev.to editor.

Let me know if you'd like a different title, a more literal translation of any specific section, or if you want me to save this as a file in the repo (e.g., outside public/ so the Qiita CLI doesn't pick it up).

I tried out "1-bit LLM Bonsai" using the Linux terminal app on my Google Pixel 7a.

Rev — Wed, 15 Apr 2026 15:59:09 +0000

Introduction

I tried running PrismML's 1-bit LLMs, Bonsai-8B and Bonsai-1.7B, on the Linux terminal app on a Google Pixel 7a. Bonsai-8B has a compact model size of just 1.15GB and reportedly runs on a Raspberry Pi 4B. Since it was described as "An 8-billion-parameter LLM that 'runs on a smartphone' — '1-bit Bonsai' at 1.15GB claiming production-level performance draws attention," I decided to test whether it actually runs on a smartphone.

References

https://prismml.com/news/bonsai-8b

https://qiita.com/y0kud4/items/3f7faeea52d7eec01b0f

https://qiita.com/moritalous/items/96cdc8bcd48d8a193556

https://qiita.com/revsystem/items/7ad150a7f99aaea27691

https://zenn.dev/kun432/scraps/ce16474a3be277

Test Environment

Google Pixel 7a
Android 16
Linux terminal

Setup

Enabling the Linux Terminal app

To enable the Linux terminal app on a Pixel device, refer to the article Running AWS Bedrock API Using Google Pixel's Linux Terminal app.

Building llama.cpp

Build llama.cpp by following this article:

https://qiita.com/moritalous/items/96cdc8bcd48d8a193556

Install the packages required for the build:

sudo apt update
sudo apt install -y git cmake build-essential libopenblas-dev pkg-config openssl libssl-dev

Clone the llama.cpp fork maintained by PrismML:

git clone https://github.com/PrismML-Eng/llama.cpp && cd llama.cpp

Build the project. This takes approximately 15 minutes.

cmake -B build -DGGML_BLAS=ON -DGGML_BLAS_VENDOR=OpenBLAS
cmake --build build --config Release -j2

Running the Models

Since the Pixel's Linux terminal app does not support Japanese input, I used a simple prompt: 'hello'. Both models produced streaming output too slowly to be practical on the Pixel's Linux terminal app. Additionally, the Linux terminal app crashed frequently, requiring a full recovery each time, so I was only able to test the following two patterns.

Bonsai-8B

The first run takes longer because the model needs to be downloaded. When the context size was not specified with -c, a Segmentation fault occurred. Following the advice at https://zenn.dev/kun432/scraps/ce16474a3be277#comment-3592ca1fdb0075, I set the context size to 32784.

./build/bin/llama-cli \
  -hf prism-ml/Bonsai-8B-gguf \
  -p "hello" \
  -c 32784

The results were as follows:
[Prompt: 1.5 t/s | Generation: 0.1 t/s]

Bonsai-1.7B

Similarly, I ran Bonsai-1.7B. This model did not require specifying the context size.

./build/bin/llama-cli \
  -hf prism-ml/Bonsai-1.7B-gguf \
  -p "hello"

The results were as follows:
[Prompt: 4.4 t/s | Generation: 1.5 t/s]

Conclusion

I tested Bonsai-8B and Bonsai-1.7B on the Google Pixel 7a's Linux terminal app. I confirmed that both models run. However, despite being lightweight models, the devices' performance was insufficient for practical use. That said, the fact that the build completed successfully was an interesting finding.

Running an AWS Lambda + Route 53 DDNS Client on EdgeRouter X

Rev — Fri, 10 Apr 2026 18:07:44 +0000

Introduction

My home network is assigned a dynamic global IP address by the ISP, so DDNS is essential for inbound connections. I built a system that periodically updates DNS records from an EdgeRouter X using the serverless DDNS solution (Lambda + Route 53 + DynamoDB) published by AWS.

This article covers the steps from setting up the AWS environment to configuring the client on the EdgeRouter X and verifying operation.

The ultimate goal is to connect to the EdgeRouter X via remote access VPN using DDNS, but first we need to build the DDNS infrastructure.

For details on how the solution works, see Building a Serverless Dynamic DNS System with AWS.

References

Test Environment

Tested on EdgeRouter X (ER-X) firmware 3.0.1.

About the Forked Repository

I forked the official AWS repository awslabs/route53-dynamic-dns-with-lambda and created revsystem/route53-dynamic-dns-with-lambda.

The fork includes the following changes, organized by branch:

fix/lambda-security: Fixed security vulnerabilities in the Lambda function (timing attack, input validation, exception handling, information leakage). Improved code quality (resolved function name conflicts, unified return types, moved boto3 to module level, removed Python 2 compatibility code).
fix/cdk-improvements: Tightened IAM policy resource restrictions (Route 53, CloudWatch Logs). Changed DynamoDB RemovalPolicy to RETAIN and billing mode to PAY_PER_REQUEST. Set Lambda log retention period and reserved concurrency. Removed unused imports and improved CDK-Nag suppressions.
fix/client-scripts: Fixed variable quoting, operator errors, deprecated command substitutions, and JSON construction safety in dyndns.sh. Added JSON injection prevention, improved exception handling, and secret masking in newrecord.py.
test/add-tests: Completely rewrote the unimplemented tests (all assertions were commented out). Added 7 CDK stack tests and 15 Lambda unit tests (22 total). Covers GET/SET normal cases, validation, authentication, and error handling.
docs/fix-typos-and-docs: Fixed typos in README.md and invocation.md. Updated response examples in invocation.md to match the Lambda implementation. Added version range specification to requirements.txt. Updated cdk.json feature flags.
fix/cdk-nag-log-retention: Added CDK-Nag suppressions for the custom resource Lambda auto-generated by the log_retention setting. Since the CDK internal resource cannot be modified, the suppression includes an applies_to clause with documented rationale.
feat/manage-record-script: Created managerecord.py to allow viewing configuration, immediately changing TTL, and deleting records via subcommands.

CDK-Nag is a tool that automatically checks CDK applications against security and compliance best practices. Error-level violations cause cdk synth to fail, blocking deployment. Warning-level violations do not block deployment. To intentionally exempt a rule, you set a suppression with a documented reason.

Setting Up the AWS Environment

Prerequisites

A domain hosted in Route 53
Permissions to operate Lambda, DynamoDB, and Route 53
An environment with the AWS CLI available

Architecture Overview

[Operator]
  |
  |-- newrecord.py (create/update) --> DynamoDB (hostname -> JSON)
  |
[EdgeRouter X]
  |-- dyndns.sh --> Lambda URL --> Lambda --> DynamoDB + Route 53

Deploying the CDK Stack

This solution is deployed using AWS CDK. The Lambda function, DynamoDB table, and IAM roles are created at once.

Clone the repository:

git clone https://github.com/revsystem/route53-dynamic-dns-with-lambda.git

cd route53-dynamic-dns-with-lambda

Install the Python dependencies:

pip install -r requirements.txt

Bootstrap is required the first time you deploy to a given account and region combination (environment). If the account is the same but the region differs, run it separately for each region.

cdk bootstrap

If you are told the CDK CLI version is too old, update it:

sudo npm install -g aws-cdk

Deploy the stack:

cdk deploy

When the deployment completes, the Lambda function URL is output. You will use this URL in the client configuration later.

Configuring the DNS Record

Run newrecord.py to interactively configure the Route 53 hosted zone and record set. The configuration is saved to the DynamoDB table.

python3 newrecord.py

If your AWS profile or region differs from the defaults, specify the environment variables:

AWS_PROFILE=production AWS_DEFAULT_REGION=us-east-1 python3 newrecord.py

Enter the hosted zone name (e.g., example.jp), hostname (e.g., router.example.jp), TTL (default 60), and shared secret in order. If the hosted zone does not exist, you will be asked whether to create it.

The shared secret, together with the Lambda function URL, is the key to authentication. Set it to a sufficiently complex string. Using a random string generated by openssl rand -hex 32 is recommended.

Once the input is complete, a confirmation is displayed:

##############################################
#                                            #
# The following configuration will be saved: #
#                                            #
  Host name:  router.example.jp
  Hosted zone id: ZXXXXXXXXXXXXXXXXXXXXXXX
  Record set TTL: 60
  Secret: ********
#                                            #
#      do you want to continue? (y/n)        #
#                                            #
##############################################

When the setup is complete, the parameters needed to run dyndns.sh are displayed:

./dyndns.sh -m set -u https://XXXXXXXXXX.lambda-url.REGION.on.aws/ -h router.example.jp -s <YOUR_SECRET>

Take note of the Lambda function URL and shared secret. They will be used in the EdgeRouter X configuration.

Verification

Test-run dyndns.sh to verify the integration between the Lambda function and Route 53. On environments that use shasum, you may need to install perl-Digest-SHA.

sudo yum install perl-Digest-SHA

Test the IP address retrieval:

./dyndns.sh -m get -u "https://XXXXXXXXXX.lambda-url.REGION.on.aws/"

If a public IP address is returned, the Lambda function is working correctly.

DDNS Client Implementation Approach

EdgeRouter X has a built-in DDNS feature that can be configured with set service dns dynamic. Internally it runs ddclient and supports standard protocols such as dyndns2 and cloudflare.

However, the AWS DDNS solution uses a protocol that sends an HTTP POST with JSON to a Lambda function URL and performs application-level authentication using a SHA-256 hash. The Lambda function URL itself is published with authentication type NONE (public access), and authentication is achieved by verifying the hash value included in the request within the Lambda function. Since ddclient does not have a definition for this protocol, the built-in DDNS feature cannot be used.

Instead, we periodically execute the shell script dyndns.sh provided in the repository using the EdgeRouter X task scheduler.

Note: The following steps are executed on the EdgeRouter X CLI or via SSH.

Deploying dyndns.sh

SSH into the EdgeRouter X and download the script. Files placed under /config/scripts/ are preserved after firmware upgrades.

curl -o /config/scripts/dyndns.sh https://raw.githubusercontent.com/revsystem/route53-dynamic-dns-with-lambda/master/dyndns.sh

chmod +x /config/scripts/dyndns.sh

dyndns.sh internally uses shasum -a 256 to generate the authentication hash. Firmware 3.0.1 includes the shasum command, so no script modification was needed. If shasum is not found on older firmware, you can replace the relevant line with openssl dgst -sha256.

Verifying dyndns.sh

IP Address Retrieval Check

First, use the -m get mode to verify that the connection to the Lambda function URL and IP address retrieval succeed.

/config/scripts/dyndns.sh -m get -u "https://XXXXXXXXXX.lambda-url.REGION.on.aws/"

If a global IP address is returned, the network connection and Lambda function are working correctly. If nothing is returned, check the Lambda function URL, DNS resolution, or firewall rules.

DNS Record Update Check

Next, use the -m set mode to actually update the Route 53 record.

/config/scripts/dyndns.sh -m set \
  -u "https://XXXXXXXXXX.lambda-url.REGION.on.aws/" \
  -h "router.example.jp" \
  -s "<YOUR_SECRET>"

On success, a response like the following is returned:

{
    "return_status": "success",
    "return_message": "router.example.jp has been updated to XXX.XXX.XXX.XXX",
    "status_code": "201"
}

If the IP address has not changed, the following response is returned. This is also normal behavior.

{
    "return_status": "success",
    "return_message": "Your IP address matches the current Route53 DNS record.",
    "status_code": "200"
}

Creating a Wrapper Script

Since dyndns.sh operates via command-line arguments, prepare a wrapper script for the task scheduler to call.

cat << 'EOF' > /config/scripts/run-ddns.sh
#!/bin/bash
/config/scripts/dyndns.sh \
  -m set \
  -u "https://XXXXXXXXXX.lambda-url.REGION.on.aws/" \
  -h "router.example.jp" \
  -s "<YOUR_SECRET>" \
  >> /var/log/aws-ddns.log 2>&1
EOF

chmod +x /config/scripts/run-ddns.sh

Registering with the Task Scheduler

Configure the task scheduler in EdgeOS CLI configuration mode:

configure
set system task-scheduler task aws-ddns interval 300m
set system task-scheduler task aws-ddns executable path /config/scripts/run-ddns.sh
commit
save
exit

This runs run-ddns.sh every 300 minutes (5 hours). Adjust the interval value based on how frequently your ISP changes your IP address.

Verifying the Configuration

Check the task scheduler registration:

configure
show system task-scheduler
exit

Verifying the DNS Response

Verify that the record has been correctly reflected in Route 53. There is one caveat here: the EdgeRouter X CLI is Vyatta-based and interprets ? as a help invocation key. This behavior persists even in operational mode (the $ prompt). Therefore, you cannot paste a URL containing ? directly into the CLI.

To work around this, create and execute a script file with vi. Using echo does not help because the CLI still interprets the ?.

vi /tmp/dnscheck.sh

Write the following content and save:

curl -s "https://dns.google/resolve?name=router.example.jp&type=A"

Execute the script:

sh /tmp/dnscheck.sh

If everything is working, JSON like the following is returned:

{
  "Status": 0,
  "TC": false,
  "RD": true,
  "RA": true,
  "AD": false,
  "CD": false,
  "Question": [{"name": "router.example.jp.", "type": 1}],
  "Answer": [{"name": "router.example.jp.", "type": 1, "TTL": 60, "data": "XXX.XXX.XXX.XXX"}],
  "Comment": "Response from 205.251.196.248."
}

If the IP address in the data field under Answer matches the WAN interface IP address, the DDNS setup is working correctly. You can check the WAN IP address with show interfaces. The 205.251.196.248 in the Comment is a Route 53 nameserver IP address, indicating that the record is being served from the AWS side.

If you want to use dig or nslookup, you can install the dnsutils package, but the EdgeRouter X has limited storage (256MB NAND). For simple DNS verification, the method above is sufficient, and it is best to avoid installing unnecessary packages.

ping can also be used as a verification method that does not involve ?:

ping router.example.jp

The first line shows PING router.example.jp (XXX.XXX.XXX.XXX), revealing the resolved IP address. When run from the LAN behind the router, the ping targets the router's own WAN IP address, so no reply is returned. Stop with Ctrl+C. Use this only to verify whether name resolution succeeds.

Checking the Logs

The execution results of run-ddns.sh are appended to /var/log/aws-ddns.log.

cat /var/log/aws-ddns.log

Task scheduler execution may not be recorded in the system log. Verify scheduler operation by checking the log output in /var/log/aws-ddns.log.

Managing DNS Records

Use managerecord.py to view, modify, or delete configurations set by newrecord.py. The DynamoDB table name is automatically resolved from CloudFormation, so you do not need to look it up manually.

Reconfiguring / Changing the Shared Secret

Re-running newrecord.py overwrites the configuration for the same hostname. Use this method to change the TTL or shared secret.

Viewing the Current Configuration

python3 managerecord.py show router.example.jp

Displays the configuration stored in DynamoDB along with the current IP and TTL from Route 53.

Hostname        : router.example.jp
Hosted zone ID  : ZXXXXXXXXXXXXXXXXXXXXXXX
TTL             : 60
Secret          : ********
Current IP      : XXX.XXX.XXX.XXX
Route 53 TTL    : 60

Immediately Applying a TTL Change

The Lambda function only checks for IP address changes and does not compare TTL values. Therefore, the Route 53 TTL is not updated unless the IP address changes. To apply a TTL change immediately, use the update-ttl subcommand.

python3 managerecord.py update-ttl router.example.jp 300

This updates both the DynamoDB TTL and the Route 53 record simultaneously. From the next IP address change onward, the updated TTL is automatically applied.

Deleting a Record

To delete only the DynamoDB record:

python3 managerecord.py delete router.example.jp

To also delete the Route 53 DNS record, add --also-route53:

python3 managerecord.py delete --also-route53 router.example.jp

In both cases, a confirmation prompt is displayed before execution.

Conclusion

I built a DDNS client that updates Route 53 DNS records from an EdgeRouter X using AWS Lambda + Route 53 + DynamoDB. This allows DDNS operation entirely within the AWS ecosystem, without depending on external DDNS services.

Since this solution retrieves the IP address and calls the Lambda function URL using curl in a shell script, it can be adapted to other network devices or servers that support curl and a scheduler such as cron.

The AWS repository does not provide a way to modify or delete configurations, so I created managerecord.py to fill that gap. It supports viewing configurations, immediately changing TTL, and deleting records via subcommands.