Coder Legion - Recent posts tagged networking

I Made AURA: A Windows 10 L2TP/IPsec VPN Client Written From Scratch in Python

Mon, 26 Oct 2026 13:22:30 +0000

For work I needed to connect to a private network over L2TP/IPsec. The VPN client built into Windows 10 refused to connect at all, and it gave me nothing to debug with: no log of the key exchange, no hint about which step failed. I went looking for another program that could do the job and found nothing suitable

This became the reason for creating AURA — a VPN client that speaks the whole protocol itself, so when something goes wrong you can see exactly where

🔐 What is it?

AURA is a Windows 10 L2TP/IPsec VPN client with its own IKEv1, ESP, L2TP and PPP stack, written in pure Python with PyQt5. The traffic goes through a Wintun virtual adapter, the driver from the WireGuard project. Nothing of Windows' built-in VPN client is used: no RAS connection, no rasdial, no Windows VPN service. The program needs administrator rights at launch, because the adapter, routes and DNS are system changes, and asks for them once through UAC

🖥️ Screenshots

⚙️ How does it work?

You enter a server, a username, a password and, when the server wants one, a pre-shared key, then press CONNECT. AURA offers the server 18 IKE proposals (AES/3DES, SHA-256/SHA-1, DH 14/5/2) and uses whichever it picks, opens one L2TP tunnel and session, authenticates with MS-CHAPv2, CHAP or PAP, whatever the server asks for, and gets its address and DNS over IPCP. The status bar and the log panel walk through every stage

The most interesting part was a bug I could not see. After a successful key exchange the server's replies were reaching the network card, but my socket received nothing. Windows hands ESP packets that arrive on UDP port 4500 to its own IPsec driver, and a user-mode socket bound to that port sees only the IKE messages. The fix was to send from an ephemeral local port: the server answers whatever port it observes

Because the program changes routes and DNS, every change is recorded before it is made, and the next launch removes whatever a crash left behind. Your credentials stay on your machine: a password and a pre-shared key are written to disk only when you tick Remember, as a DPAPI blob that opens for your Windows account alone, and they never reach the log

✨ Key Features:

🔐 Own IKEv1/IPsec Stack
Main and quick mode with a pre-shared key, NAT traversal and dead peer detection. Offers 18 proposals (AES/3DES, SHA-256/SHA-1, DH 14/5/2) and uses whichever the server picks
🧵 L2TP + PPP
One tunnel and session with keepalive, then MS-CHAPv2 / CHAP / PAP (whatever the server asks for), IPCP for the address and DNS, and MPPE where a server demands it
🛡️ Wintun Virtual Adapter
Traffic goes through a real Wintun adapter named AURA. Route all sends everything through the tunnel, or list your own networks in extraRoutes
🗂️ Connection Profiles
Several saved servers in a combo box. Password and pre-shared key are kept only on request, protected with DPAPI
🧹 Crash Recovery Sweep
Every route, DNS entry and the adapter are recorded before they change, and the next launch removes whatever a crash left behind

🗺️ Roadmap:

In-place IPsec Rekey — Renew the security association before it expires. Today the session ends when the server drops it
IKEv2 — A second protocol next to IKEv1
Certificates — Authentication beyond the pre-shared key
IPv6 — Addresses and routes inside the tunnel
Tray Icon — Live in the notification area
Automatic Reconnect — Come back after a lost link
Kill Switch — No traffic outside the tunnel while it is meant to be up
L2TP Tunnel Secret — Servers that authenticate the tunnel itself with a shared secret are refused today

🔗 Repository Link

https://github.com/m-o-z-z-i-x/AURA

A Practical Periodic VPN Access Review for Small Teams

Thu, 15 Oct 2026 08:29:16 +0000

This checklist shows how to review people, devices, profile revisions and pending setup records using existing approved sources. Each unresolved item should end with an owner and a next action.

Adapted with permission from A Periodic VPN Access Review Checklist for Small Teams by Mohammad Hesameddin Montazerilisar, published July 10, 2026 and updated July 11, 2026. AI assistance was used for editing, the introduction and reference notes; the substantive source checklist is retained. The author writes technical guidance for Lisar Connect, operated by MONTAZERI COMPUTERS & REQUISITES TRADING CO. L.L.C.

AI-generated conceptual illustration of a VPN access review; not an application screenshot.

A periodic access review is a short check that the team’s VPN assignments still match real people, real devices, and current needs. It is not a live-session audit and it does not require collecting profile files or credentials.

For a small team, the review can be a 20–30 minute pass through the access inventory after staff changes, device replacements, or profile updates.

Prepare three simple sources

Before starting, gather:

the current team or contractor list;
the VPN access inventory;
the current profile labels or status information available through the approved source.

That is usually enough. Do not ask people to send their profile files, passwords, tokens, or screenshots containing sensitive details.

Check people and responsibilities

Start with the roster:

Has anyone left the team?
Has a contractor’s task ended?
Has someone changed role or no longer needs the same assignment?
Does every shared office device have a named responsible person?
Is anyone listed twice under slightly different names?

Update the inventory or create a clear follow-up item for anything that no longer matches. The review should make ownership clearer, not simply produce more notes.

Check devices

Next, compare each assignment with the device it is meant for:

Is the laptop, phone, or router still in use?
Was the device replaced, lost, retired, or reassigned?
Does the profile label match the current device name?
Is an old device still shown as active in the inventory?

A profile file remaining on an old device does not prove that the assignment is current. Use the approved status source and the inventory rather than guessing from local files.

Check profile revisions

Look for profiles that were replaced or reissued:

Does the inventory show the newest approved revision?
Are any users still referring to an older filename or client entry?
Was a recent reissue checked on the intended device?
Are similar profile names causing confusion?

The review does not need the technical contents of either version. It only needs a clear old-to-current relationship.

Check records that are waiting for action

Pay attention to statuses such as:

Awaiting setup
Needs review
Device replacement pending
Profile update not yet checked
Owner unclear

For each one, decide one next action and one person responsible for it. Keep the note simple: what needs to happen and when it should be checked again.

Avoid leaving vague entries such as temporary, maybe old, or ask later with no owner.

Check the setup documentation

A quick review should also confirm that the team’s setup notes still point to:

the correct supported client;
the current profile source;
the right import/save steps;
the current connection-check instructions;
relevant troubleshooting articles;
a named document owner.

Remove or replace screenshots that show outdated menus or unnecessary personal information. Do not add profile contents or credentials in an attempt to make the guide more complete.

Use a short review checklist

A practical sequence is:

Compare the inventory with the current roster.
Confirm each active assignment has a clear owner and purpose.
Check whether the listed device is still in use.
Confirm the recorded profile revision is current.
Review assignments marked Awaiting setup or Needs review.
Check recent onboarding, offboarding, and device-replacement changes.
Confirm shared equipment has a responsible owner.
Update stale setup links or screenshots.
Assign a next step to anything unresolved.
Record when the next review should happen.

The result should be a cleaner, more accurate inventory—not a collection of secrets or an oversized audit report.

Decide how often to review

The right cadence depends on how often the team changes. A stable team may only need a quarterly check. A team with frequent contractors or device changes may benefit from a monthly review.

Also run a focused review after:

several people join or leave;
a group of devices is replaced;
profiles are reissued;
responsibility for setup changes;
the inventory has not been updated for a long period.

What a useful outcome looks like

At the end of the review:

active assignments match current people and devices;
unclear or old records have a next action;
the current profile revision is easy to identify;
shared equipment has a named owner;
setup documentation still matches the approved process;
no profile files or credentials were collected.

That is enough for a small-team review. Formal audit terminology and complex approval chains are unnecessary unless the organization already has a documented process that requires them.

Frequently asked questions

Is this the same as monitoring active VPN sessions?
No. It reviews assignments, devices, and records. It does not show who is connected at a specific moment.

How often should we run the checklist?
Use a cadence that matches team changes—often monthly or quarterly—and run an extra check after significant onboarding, offboarding, device replacement, or profile reissue work.

Should reviewers collect profile files to confirm the revision?
No. Use non-sensitive profile labels, inventory records, and the approved status source. Do not collect profile contents or credentials.

What should happen when something is unclear?
Assign one owner and one next step. A clear follow-up is more useful than a long note with no decision.

Technical references for the review

OpenVPN connection profiles explains why profile files contain sensitive connection material. Use labels and approved status sources in the review.
Editing an OpenVPN Connect profile distinguishes the displayed profile name from other parameters. A naming mismatch is a reason to confirm the intended assignment, not to change server settings by guesswork.
Deleting a local OpenVPN Connect profile removes its entry from that app. Treat local cleanup and service-side access removal as separate tasks.

These client references were checked on October 15, 2026. They support the operational distinctions above; this article does not report a live test of any team's access or client. Follow the organization's documented process where it requires additional controls.

How to Name VPN Profiles for Clear Team Handoffs

Wed, 14 Oct 2026 08:18:23 +0000

This guide sets out a small naming convention for issued VPN profiles. It covers readable assignment labels, revision suffixes, matching client names, and what to keep out of filenames.

Adapted with permission from A Practical VPN Profile Naming Convention for Small Teams by Mohammad Hesameddin Montazerilisar, published July 10, 2026 and updated July 11, 2026. AI assistance was used for editing, destination framing, and reference notes; the substantive guidance below preserves the human-authored source. The author writes technical guidance for Lisar Connect and is Manager of MONTAZERI COMPUTERS & REQUISITES TRADING CO. L.L.C. The examples are illustrative, not real access records.

Cover: AI-generated illustration. Example filename is fictional.

A profile name should help someone choose the right connection without opening the file, guessing from a download date, or asking who created it. For a small team, that does not require a complicated asset-management system. A short, repeatable pattern is usually enough.

The useful question is simple: can a teammate identify the owner, device, purpose, and current revision from the name alone? If the answer is yes, the naming convention is doing its job.

Start with the four details people actually need

Most teams only need four pieces of information:

Owner or role — who the profile is assigned to.
Device — which laptop, phone, or router it is intended for.
Purpose — normal work, travel, shared office, testing, or another approved use.
Date or revision — enough to distinguish the current copy from an older one.

A practical pattern is:

owner-device-purpose-revision

Examples:

mina-laptop-work-r03.ovpn
sales-router-office-r02.ovpn
contractor7-phone-travel-2026-07.ovpn

The separator and exact order are less important than consistency. Pick a pattern that remains readable in a downloads folder and inside the VPN client.

Use labels people already understand

A naming convention should reduce explanation, not create a new internal language. Use names that your team already recognizes:

a person’s first name or approved staff ID;
a short device label already used by the team;
a plain purpose such as work, travel, or office;
a simple revision such as r02 or a date such as 2026-07.

Avoid codes that only one administrator understands. If a profile called EU-7B-X4 requires a separate spreadsheet just to decode it, the name is not helping the person who needs to import it.

Keep filenames and client names aligned

A common source of confusion is a clear filename that becomes a vague client entry after import. When the client allows a display name, use the same identifying pattern or a shortened version of it.

For example:

file: mina-laptop-work-r03.ovpn
client entry: Mina — Laptop — Work — R03

The two names do not need to be character-for-character identical, but they should point to the same owner, device, purpose, and revision. That makes screenshots, support conversations, and future setup checks much easier to follow.

Do not put sensitive information in the name

A profile name is visible in folders, screenshots, backups, and client interfaces. Keep it descriptive but non-sensitive.

Do not include:

passwords or verification codes;
private keys or certificate values;
full email addresses when a short approved identifier is enough;
payment information;
internal server secrets;
detailed infrastructure notes.

A name should identify the assignment, not reveal how the profile works internally.

Make the current revision obvious

When a profile is replaced, the new name should make the change visible. A simple revision suffix works well:

r01 — original issue
r02 — replacement or updated profile
r03 — next approved revision

A date can work too, especially when profiles are refreshed infrequently. Avoid informal endings such as final, final2, new, and newest. Those labels become unreliable as soon as another copy is issued.

The current profile should also be reflected in the team’s access inventory or setup notes. The filename alone should not be the only record of which revision is current.

Keep the convention short enough to use

A naming rule can become counterproductive if it tries to encode every fact. The purpose of the name is quick recognition, not complete documentation.

Good names are:

short enough to scan;
specific enough to distinguish assignments;
consistent across the team;
safe to show in a screenshot;
stable when the file moves between folders or devices.

Details such as who approved the assignment, when access should be reviewed, and why a change was made belong in the access inventory or change note, not in the filename.

Introduce the pattern without renaming everything at once

A small team can adopt a naming convention gradually:

Agree on one pattern.
Use it for every newly issued or replaced profile.
Rename current local copies only after confirming which file is active.
Update the matching client display name where the client supports it.
Record the current revision in the access inventory.
Stop creating new filenames with informal suffixes.

There is no need to reopen or edit profile contents just to improve the filename. Renaming the local file is ordinary file organization; the actual profile data should remain unchanged.

Quick checklist

Before accepting a profile name, check that it answers:

Who or what is it for?
Which device is it intended for?
What is its approved purpose?
Which revision or issue date is current?
Is the name free of secrets and unnecessary internal detail?
Will the same label make sense inside the VPN client?

If the name answers those questions at a glance, it is probably good enough.

Frequently asked questions

Should a profile name include the server country or location?

Only when location is a documented and stable part of the assignment. Do not encode assumptions that may change, and do not use the name to imply account-region or service-eligibility changes.

Is a date better than a revision number?

Either can work. Dates are easy to sort; revision numbers are compact. The important point is to use one method consistently and record which version is current.

Can I rename an .ovpn file after downloading it?

A local filename can normally be renamed without changing the file’s contents. Confirm that you are renaming the intended current copy, and do not manually edit sensitive profile sections.

Should every user follow the same convention?

For a team, yes. A shared pattern makes support and handoff easier, even if each person’s actual profile remains assigned individually.

Official references and the limits of a label

OpenVPN Connect: Connection Profiles explains that the profile contains connection parameters and certificates. A readable filename is an organizational label; it is not proof of the file contents or current access.
OpenVPN Connect: Edit a Profile documents the Profile Name field and notes that a connected profile cannot be edited. Use the supported naming control when appropriate; do not change server overrides, proxies, or connection data as a naming exercise.
OpenVPN Connect: Import a Profile documents importing a profile from a file or URL. Importing and naming are separate from proving an active connection.

These references were checked on October 14, 2026. No device, VPN service, or client behavior was tested for this article. Follow the approved procedure for your actual client and managed device.

A Controlled Method for Comparing VPN IP-Check Results

Tue, 13 Oct 2026 08:18:16 +0000

A useful IP-check comparison records the address family, raw address, timing, and lookup labels separately. This keeps a database disagreement from becoming an unsupported diagnosis.

Adapted with permission from the original Lisar article by Mohammad Hesameddin Montazerilisar, published July 10, 2026 and updated July 11, 2026. AI assisted editing, platform framing, and fact-checking; the substantive source guidance is human-authored. No client, service, or IP-geolocation test was performed for this article.

AI-generated illustration of one laptop with three differing map estimates; not a measured network result.

Two IP-checking websites can inspect the same public IP address and display different cities, network names, or location labels. That does not necessarily mean the VPN connection changed between pages. Most IP-checking services combine the observed address with their own databases, update schedules, and labeling rules.

The IP address is the direct network observation. The city, region, provider, or “type” shown beside it is an interpretation.

An IP address can have several public descriptions

An IP-checking page may show:

public IPv4 address;
public IPv6 address;
country or region;
city;
internet service provider or network operator;
autonomous-system organization;
hosting, mobile, corporate, or proxy classification;
reverse-DNS name;
time zone inferred from location.

These fields do not all come from the same source or have the same accuracy. The IP address observed by the site is usually the most direct result. The descriptive fields are database records or estimates.

Why lookup databases disagree

IP ranges are assigned and routed by network operators, but location databases are maintained by separate companies and services. They may use registration records, routing information, user corrections, network measurements, commercial feeds, or historical data.

One provider may associate a range with the operator’s registered office. Another may estimate the location of network infrastructure. A third may use a broad country-level label because it lacks reliable city data.

Updates do not arrive at the same time. A recently reassigned or newly announced range can show an old city in one database and a new country or operator in another.

Country, city, ISP, and organization fields have different accuracy

Country-level data is often more stable than city-level data, but neither should be treated as a guaranteed physical location. A city result can represent the network’s registration, routing point, or database estimate rather than the exact server or user position.

The “ISP” or “organization” field can also differ. One service may display the company that owns the address range, another the network that announces it, and another a brand or hosting provider.

A label such as hosting or proxy is a classification produced by that service. It is not a universal fact shared by every website.

IPv4 and IPv6 can produce different observations

A device may have both IPv4 and IPv6 connectivity. Different test sites, browsers, or applications may prefer one protocol over the other. If the VPN or local network handles them differently, one page can report an IPv4 address while another reports an IPv6 address.

That is why an IP test should state which address family it observed. Do not assume two different-looking addresses represent two random results when one is IPv4 and the other is IPv6.

A complete investigation may require checking both protocols according to the documented setup. Avoid changing network or router settings as a general response.

Cache and update timing matter

Browsers, DNS resolvers, content-delivery networks, and the IP-checking service itself can cache results. A page may also load some information from a previous request while another field is refreshed.

Repeat the test in a controlled way rather than refreshing many pages rapidly. Confirm the VPN status, note the time, and record the raw public IP shown by each service. If the raw address is the same while the city differs, the disagreement is clearly in the database description.

Use a controlled IP-check method

Confirm the VPN client reports Connected.
Record the profile or intended connection in non-sensitive terms.
Close or avoid pages that requested browser location permission.
Open two or three reputable IP-checking services.
Record the exact IPv4 and IPv6 addresses shown.
Record country, city, and network labels separately.
Repeat once after a short interval if necessary.
Compare the raw addresses before comparing location names.

Do not grant precise browser location permission during a basic IP test. That would introduce a different signal.

What a disagreement does and does not prove

If two sites show the same IP but different cities, the VPN connection can still be functioning normally. The sites are interpreting the same address differently.

If they show different public IPs at the same time, check whether:

one result is IPv4 and the other IPv6;
the VPN changed state between tests;
the browser used a cached result;
different applications are using different network paths;
a network transition occurred;
one page displayed a browser-location result instead of IP geolocation.

A differing city does not prove a leak. A matching city does not prove complete privacy or security. The meaning depends on the raw address and the test method.

How to report a meaningful result

A useful report includes:

date and time;
VPN client status;
device and network type;
test-service names;
raw IPv4 and IPv6 results;
location and organization labels from each service;
whether browser location permission was blocked;
whether the result was repeatable.

Do not include profile files, credentials, tokens, or internal configuration.

Why the answers can disagree

IP-check services rely on separate databases and update schedules. Two sites can map the same public IP differently without proving that the VPN connection is switching locations. Confirm the actual public IP first, then treat the displayed city as an estimate rather than an exact device position.

Frequently asked questions

Which IP-checking site is correct?

They may all observe the same IP while using different descriptive databases. The raw address is more direct than the city label.

Why does one site show a nearby city and another a distant city?

City-level IP geolocation is approximate and may reflect registration or network infrastructure rather than exact physical location.

Can IPv4 and IPv6 show different locations?

Yes. They are different address ranges and may have different database records or network paths.

Does a wrong city mean the VPN is not connected?

No. Confirm the client status and raw public IP before interpreting the city estimate.

Should I grant browser location permission for an IP test?

No. That introduces device location and makes the result harder to interpret.

Authoritative references

MaxMind: Geolocation accuracy — limitations, differing databases, and location estimates.
IETF RFC 8305: Happy Eyeballs Version 2 — background on connection attempts across IPv4 and IPv6.
MDN: Geolocation API — browser permission and device-provided location.

Author affiliation: Mohammad Hesameddin Montazerilisar writes and maintains Lisar Connect technical guidance and is Manager of MONTAZERI COMPUTERS & REQUISITES TRADING CO. L.L.C. This article gives general diagnostic guidance and makes no product compatibility, privacy, or access guarantee.

17NAS IPv6 Test

Mon, 12 Oct 2026 16:22:24 +0000

17NAS IPv6 Test — free online IPv6 connection test

Not sure if your network really supports IPv6? This free tool checks it in real time, right in your browser.

What it shows:

Your IPv4 and IPv6 addresses side by side
Connection latency for each protocol
ISP information
Dual-stack status and a connection quality score

It runs both protocols in parallel, so you get the full picture in seconds. There's also a simple curl-based API if you want to script the check.

No sign-up, no uploads — everything runs locally in your browser.

Try it: https://17nas.com/ipv6-test.php

Built by the 17NAS team. Feedback welcome!

A Practical Change Record for Reissued VPN Profiles

Mon, 12 Oct 2026 08:15:40 +0000

A profile reissue needs a small, useful change record: the assignment, the old-to-new revision, and which setup stage has actually completed. The record should help the next person continue without receiving any secrets.

AI-generated illustration of six profile-handoff stages. Conceptual guidance, not a product screenshot.

When a VPN profile is replaced, the team needs a clear answer to three questions: which assignment changed, which copy is now current, and has the intended device been checked? A short change note is enough. It does not need to become a formal project or expose what is inside the profile.

The goal is to stop old and new copies from being confused during setup or troubleshooting.

Record the reason in plain language

Use a short, ordinary reason such as:

device replacement;
updated connection information;
compatibility correction;
scheduled profile refresh;
user or role change;
incorrect earlier delivery.

Do not copy sensitive configuration differences into the note. The reason should explain the operational context, not reveal credentials, keys, certificates, or internal infrastructure details.

Identify the exact assignment affected

A useful record should identify:

the person or approved role;
the intended device;
the purpose of the profile;
the previous profile label or revision;
the new profile label or revision.

For example:

Mina / Laptop-07 / Work / R02 → R03

That line is often more useful than a long paragraph because it makes the relationship between the old and new copies obvious.

Keep issue, delivery, and verification separate

A profile can be created without reaching the user, delivered without being imported, or imported without establishing a connection. Record these steps separately when they matter:

Issued — the new profile or revision became available.
Delivered — the intended user received it through the approved path.
Imported/saved — the profile was added to the intended client.
Connected — the client reached an active connection.
Checked — the user confirmed the expected basic behavior.
Inventory updated — the new revision is recorded as current.

A small team may combine some steps in one note, but it should not mark the change complete merely because a file was sent.

Tell the user which profile to select

The user-facing message should be simple:

the name of the new profile;
the device it is intended for;
the approved place to obtain it;
the basic import/save action;
how to recognize the correct client entry;
what to do if the new profile does not connect.

Avoid forwarding a profile through an informal shared channel or encouraging people to test profiles assigned to someone else.

Handle old copies without creating confusion

The record should say that the previous revision is no longer the current reference copy. The exact service-side handling belongs to the authorized process; the public note does not need to describe deletion, revocation, or internal administrative steps.

On the user’s device, the priority is making the new profile easy to identify. Clear naming and a current-revision record reduce the chance that someone reconnects with an older client entry later.

Keep the note short enough to maintain

A practical change note can fit in a few fields:

Assignment — Mina / Laptop-07 / Work
Reason — Device replacement
Previous revision — R02
Current revision — R03
Issued — 2026-07-10
Connection checked — 2026-07-11
Inventory updated — Yes
Open issue — None

Use non-sensitive identifiers. Do not attach the profile file or paste its contents into the record.

Note exceptions in a useful way

Sometimes the new profile cannot be checked immediately because a device is offline, the user is travelling, or the client needs an update. A useful exception note says:

what is waiting;
who will follow up;
the next practical step;
when it should be checked again.

That is enough. Avoid elaborate risk scoring or a long approval chain unless the team already has a documented reason to use one.

When the change is complete

Treat the reissue as complete when:

the intended user or device has the new profile;
the client entry is identifiable;
the connection has been checked where required;
the access inventory shows the new revision as current;
any unresolved exception has a clear owner and next step.

The change record should make the current state easy to understand without exposing the profile itself.

Frequently asked questions

Do we need to record exactly what changed inside the profile?

No. Record the reason and the old-to-new revision relationship. Sensitive profile contents should not appear in the change note.

Is sending the new profile enough to close the change?

Not always. Delivery and successful setup are different steps. At minimum, record whether the intended person or device completed the required check.

Should a service renewal be recorded as a profile reissue?

Only when a new profile is actually issued. Renewal and profile replacement are separate events.

What if the user still sees the older client entry?

Make the current profile label clear and follow the approved local cleanup guidance. Do not rely on trial and error with several similar profiles.

Official client references

OpenVPN documents what a connection profile contains, the separate file-import process, and where the displayed profile name is edited. These references explain client behavior; a display-name change is not a new provider-issued revision or proof of service-side access changes. Use the approved administrator or provider process for those changes.

VPN Configuration Permission: Check Consent Separately from Connection State

Sun, 11 Oct 2026 08:17:48 +0000

A VPN configuration prompt is a system permission decision. This guide separates that decision from profile import and connection state, including why switching VPN apps on Android can bring the prompt back.

Adapted with permission from the original Lisar article by Mohammad Hesameddin Montazerilisar, published July 10, 2026 and updated September 25, 2026. AI assisted editing, platform framing, and fact-checking; the substantive source guidance is human-authored. No device test was performed for this article.

AI-generated conceptual illustration: system permission and a working VPN connection are separate checks. This is not a product or operating-system screenshot.

A VPN client cannot establish a system-level VPN connection without permission from the operating system. That is why a phone, tablet, or computer may display a prompt asking whether the client can add a VPN configuration.

The wording can sound more serious than the action feels. In ordinary use, the prompt is the operating system asking whether the client may create and manage the connection entry that you are trying to set up. It is not, by itself, confirmation that the profile is correct, that access is active, or that a connection has been established.

What the permission prompt is asking

A VPN connection affects how network traffic leaves the device. Because that happens at the operating-system level, the client needs explicit permission to create a VPN configuration.

Depending on the device, the prompt may refer to adding a VPN configuration, allowing a VPN connection, or permitting the client to manage VPN settings. The exact words and screen design vary between operating systems and client versions.

This is different from a normal website permission. A browser page cannot create the system connection on its own. The compatible VPN client handles the imported or saved profile, while the operating system controls whether that client may create the VPN connection.

Why the operating system shows it

The prompt creates a clear boundary between installing or opening a client and allowing that client to affect network routing on the device. It gives the device owner a chance to confirm that the action was intentional.

You will commonly see it during first-time setup, after installing a client on a new device, or when the operating system needs fresh confirmation after a material software change. You may not see it for every later connection because the permission can remain associated with the approved client and configuration.

The absence of a new prompt does not prove that the profile is current. It only means the operating system did not need to ask for that permission again at that moment.

What to verify before approving

Use a short check rather than treating the prompt as a routine button:

Confirm the client. The application named in the prompt should be the compatible VPN client you intentionally opened.
Confirm the source. The profile should have come from a trusted and expected source. Do not use a profile passed around casually.
Confirm the device. Personal devices and organization-managed devices may follow different rules.
Confirm the action. The prompt should follow a setup action or a connection attempt you intentionally started. A new import is not required every time permission is requested.
Confirm ownership. The profile should be assigned or otherwise authorized for your use.

There is no need to open sensitive parts of a profile file to make this decision. The useful checks are source, assignment, client, device, and the action you intentionally started.

Why Android may ask again after another VPN app

Android allows one active VPN service per user or work profile. Starting a different VPN app can replace the current VPN connection. Allowing that other app can also revoke the previous app’s system approval, so returning to your usual client may bring up the permission request again. See the Android VPN guide and VpnService permission reference.

The request can appear when you tap Connect, even if the profile is already imported. The OpenVPN Connect Android guide describes granting permission at that step. A repeated request alone does not show that your profile is damaged; it is not a reason to re-import the file or reinstall the client.

Confirm the app named in the prompt and the connection you intended to start. On a managed device, follow the administrator’s VPN policy. After granting permission, check the client’s connection status separately.

What happens if you decline

If you decline, the client normally cannot create the requested system VPN configuration. The profile might still appear in the client, or the setup may remain incomplete, depending on the operating system and client.

If you are uncertain, pause or decline and verify the source before continuing. The requested configuration remains unapproved; network availability may depend on the device policy already in force.

When you return to the setup flow after verifying everything, the operating system may show the prompt again. The exact behavior depends on the device and client.

Managed devices and organization policies

A company-managed phone or computer may restrict who can add VPN configurations. It may also require a specific client, profile, or approval process.

Do not try to work around those controls. If the device blocks the action or the prompt differs from the documented setup, check with the person responsible for the device or network access. A valid profile does not override device-management policy.

This is one reason setup can differ between a personal device and an organization-managed device even when both use the same general profile type.

Permission granted does not mean connected

Approving the system prompt completes only one part of setup. Several separate states are easy to confuse:

The client is installed.
The profile is imported or saved.
The operating system has allowed a VPN configuration.
The client has attempted to connect.
The connection is active.

A successful permission step does not prove the last two states. After setup, use the client status and the normal first-connection checks to confirm whether the connection is actually active.

Frequently asked questions

Why did I see the prompt on one device but not another?

Operating systems, client versions, prior permissions, and device-management rules can produce different setup flows.

Can the request appear when I tap Connect?

Yes. On Android, a client may ask for system VPN permission when you start a connection with an already imported profile. Granting permission does not by itself confirm an active connection.

Why does Android ask again after I use another VPN app?

Allowing another VPN app can revoke the previous app’s approval. When you return to the earlier client, Android may ask for permission again. This alone does not mean the saved profile is damaged.

Original author: Mohammad Hesameddin Montazerilisar, technical author for Lisar Connect and Manager of MONTAZERI COMPUTERS & REQUISITES TRADING CO. L.L.C, which develops and operates Lisar Connect.

A Post-Restart VPN Checklist: Network Readiness, Client State, and Android Startup Settings

Sat, 10 Oct 2026 08:14:32 +0000

This checklist explains how to verify a VPN after a device restart, including network readiness and the difference between client launch settings and Android traffic-blocking policy.

Adapted with permission from the original Lisar article by Mohammad Hesameddin Montazerilisar, published July 10, 2026 and updated September 26, 2026. AI assisted editing, platform framing, and fact-checking; the substantive source guidance is human-authored. No connection test was performed for this article.

Restarting a phone, tablet, or computer ends active processes and network sessions. A VPN profile may remain saved in its client, but the connection that existed before the restart should not be assumed to remain active afterward.

The useful distinction is between stored configuration and current connection state. A restart can leave one intact while resetting the other.

What survives a restart and what does not

A saved profile is configuration information stored by the client. An active VPN session is a live network state. Most devices preserve the client and its profiles through a normal restart, but they stop the active session while the operating system shuts down.

After startup, the client may:

remain disconnected until you open it;
reconnect automatically when the operating system and network are ready;
display the saved profile but require a new Connect action;
ask for permission again after a major update or policy change;
report an error because the underlying network is not ready yet.

These behaviors vary. The presence of a profile entry does not prove an active connection, and the absence of an automatic reconnection does not by itself mean the profile is damaged.

Wait for the normal network to become usable

After startup, Wi-Fi and mobile services may take time to reconnect. A guest or public network may require a sign-in page again. A laptop can also reconnect to a different remembered network than the one used before shutdown.

Check network readiness together with any VPN policy already applied:

the expected Wi-Fi or mobile connection is active;
ordinary internet access works where device policy permits it; if non-VPN traffic is blocked, check the client status instead of treating this test as proof of a network failure;
any permitted captive-portal sign-in is complete, or the network administrator has provided an approved way to finish it;
the device is not still applying startup updates or network policy.

Starting several VPN attempts while the underlying network is changing can produce timeouts or duplicate status messages that disappear once the device is fully ready.

Android: startup and traffic blocking are different settings

On a compatible Android client, Always-on VPN can start the VPN service after boot. The client still has to establish its connection. The separate Block connections without VPN option can prevent ordinary internet access until that happens. A failed browsing test in this state does not by itself show that the saved profile is damaged. Availability depends on the client and device configuration; see the Android VPN documentation.

OpenVPN Connect has its own Android launch settings: Connect latest tries the most recently connected profile, Restore connection tries to restore the connection active before shutdown, and None takes no action after reboot. Its Always-on tutorial covers the separate system option. These examples describe OpenVPN Connect; check the documentation for the client you actually use.

Read the current client status and any system notification before deciding what failed. On a managed device, ask the administrator for an approved network test or sign-in path; do not disable a required VPN or security policy.

Confirm time and note what changed

Check that the system's actual date and time are correct. A wrong system clock can interfere with connection validation; a different time-zone display alone does not establish that problem.

Also record whether the restart followed an operating-system or client update, a reinstall, a device-management change, a restore, or a network reset. Those events can change permissions or client behavior, but the timing alone does not prove the cause.

Open the intended client and profile

Confirm that the expected client starts normally and that the intended current profile is visible. If several similarly named profiles exist, compare the approved label, assignment, or delivery date instead of choosing the first one.

A common mistake is to download the file again after every restart. That is usually unnecessary when the current profile is already saved. Repeated import attempts can create duplicate client entries and make it harder to know which one was tested.

Do not inspect, copy, or share sensitive profile contents to identify the file. Use the authorized source, visible name, revision label, user or device assignment, and service status.

Handle permission prompts carefully

A system may ask again for permission to add or use a VPN configuration after a major update, client reinstall, device migration, or policy change. Confirm that:

you intentionally opened the expected client;
the prompt names that client;
the profile came from the approved source;
you are allowed to add the configuration on this device.

On an organization-managed device, do not work around a blocked or altered prompt. Follow the approved device policy and contact the responsible administrator.

Recheck connection status instead of assuming

After the client is ready, distinguish these states:

profile is visible;
profile is selected;
client is Connecting;
client reports Connected;
ordinary internet and expected services work while connected.

A familiar system icon from before the restart is not reliable evidence. Open the client or operating-system VPN status and confirm the current state.

If the client reports Connected, use the normal first-connection verification steps documented for the service.

Avoid duplicate setup attempts

When the first attempt fails after startup, preserve the result before changing anything. Record the visible status, timing, network, client version, and whether the restart followed an update. Then compare one condition, such as waiting for the network to stabilize or trying another authorized network.

Avoid:

repeatedly importing the same file;
deleting profiles without confirming which revision is current;
manually editing .ovpn file contents;
changing router, firewall, or device-security settings;
using another person’s profile;
assuming a reinstall is always required.

Frequently asked questions

Do I need to import the profile after every restart?

Normally not when the current profile remains saved in the client. Reimport only when the documented setup or access owner requires a new file.

Can the VPN reconnect automatically after startup?

It depends on the client and approved settings. For example, OpenVPN Connect on Android documents launch choices for the last-used connection and for restoring a previously active connection. An automatic attempt is not proof that the VPN connected.

Why can internet access be unavailable until the VPN connects?

If Android is configured to block connections without VPN, ordinary traffic can remain unavailable while the client connects. Check the active policy and client status. On a managed device, ask the administrator for an approved test instead of disabling the policy.

Original author: Mohammad Hesameddin Montazerilisar, technical author for Lisar Connect and Manager of MONTAZERI COMPUTERS & REQUISITES TRADING CO. L.L.C, which develops and operates Lisar Connect.

A VPN Offboarding Checklist: Confirm Access Removal and Clear Returned Devices

Fri, 09 Oct 2026 08:15:26 +0000

Adapted from Removing VPN Access When Someone Leaves: An Offboarding Checklist by Mohammad Hesameddin Montazerilisar, published July 9, 2026 and updated September 27, 2026. AI assistance was used for editing, introductory framing, and a short reference note. The author writes for Lisar Connect and is Manager of MONTAZERI COMPUTERS & REQUISITES TRADING CO. L.L.C.

Use this checklist to coordinate a departure without confusing local file cleanup with confirmed access removal. Keep the account-side action with the authorized administrator or service support.

Per-person setup can make offboarding easier to track. When a team member leaves, identify their assigned access, confirm its removal through the authorized process, and handle returned-device cleanup separately. This is a non-technical checklist for coordinating those steps.

A note on scope up front: this article is about the team's practical offboarding steps and routing the account side to the right process. It deliberately doesn't provide technical account-side procedures — those belong to the account, admin, and official support process, not to a public checklist.

Step 1: Identify who is leaving and what they had

Start with clarity: who is leaving, and what VPN setup did they have — which devices, whose profile. Where setup is per-person, use the assignment records to identify that person’s profiles and authorized devices; verify the record rather than assuming it is complete. Knowing exactly what existed is what makes the rest of the checklist concrete rather than guesswork.

Step 2: Stop relying on any shared files

If, despite best intentions, anything was ever shared — a profile file that got forwarded, a copy in a shared folder — offboarding is the moment to stop relying on it and correct the pattern. Keep future assignments per-person, but also resolve the copies that may already exist.

If a profile or credential was shared, tell the administrator which assignments may be affected without distributing the secret again. Ask them to confirm the required invalidation or replacement. Moving future users to individual profiles does not revoke an existing shared copy.

Step 3: Follow the account and support process for access

The actual removal of access on the account side goes through the proper channel: the account, admin, and official Lisar support process. That's deliberately where it lives — not in a public how-to — because it's the correct, supported path and because the specifics belong to the team's account context.

Ask the authorized administrator or official Lisar support to remove the departing person’s access and confirm when that action is complete. Record any session termination or credential/profile invalidation that the actual service process requires. Sending a request is not confirmation that access has ended; do not mark offboarding complete while that result is unverified.

Step 4: Remove local files from returned devices

On returned devices you are authorized to administer, remove downloaded profile files and the separate imported profiles or saved VPN configurations through the client or operating-system controls. OpenVPN Connect documents profile removal from the app. Removing the download alone leaves an imported entry intact; neither local action invalidates copies on other devices.

For devices handled by your team's normal device-return process anyway, that process covers it. The deliberate file-removal step matters most for devices that are simply handed back and reused as-is. This is local file hygiene — not an account action, and not something that touches anyone else's setup.

Step 5: Update team documentation

Update the team’s records with the confirmed access-removal outcome, the returned-device cleanup outcome, and any unresolved step. Do not record the person’s offboarding as complete merely because a request was sent. If the team keeps a simple setup document, note the change there so the picture stays current for whoever onboards or offboards next.

What offboarding must not involve

Two firm boundaries. First, no sharing of sensitive material as part of offboarding — no passing around the departing person's profile file, credentials, or screenshots of setup details "to sort things out." Departure is not a reason to move material that shouldn't move at any time. Second, no improvised technical removal — access removal is the account/admin/support process's job, and a team's role is to initiate and follow it, not to invent steps.

Use documentation for the actual system

The OpenVPN Connect instructions linked above describe removing an imported profile from that client; they do not document revoking a Lisar account. For a separate identity-system example, Microsoft’s Entra access-revocation guidance distinguishes account controls from session and token behavior. This illustrates why completion depends on the actual service. It does not imply Lisar uses Entra or shares its procedures or timing.

Two questions to close before offboarding is complete

What if a profile file was shared before we knew better?

Notify the administrator or official support and confirm whether the shared credential/profile must be invalidated or replaced. Do not assume that deleting a file or moving future users to individual profiles disables earlier copies.

What can we do on the device side during offboarding?

On returned devices you are authorized to manage, remove downloaded files and imported client profiles or saved configurations using the documented controls. Keep account-side access removal separate and confirm it through the administrator or official support.

A Diagnostic Order for Video-Call Problems While a VPN Is Connected

Thu, 08 Oct 2026 08:17:52 +0000

Adapted from VPN and Video Calls: Realistic Expectations by Mohammad Hesameddin Montazerilisar, published July 9, 2026 and updated September 27, 2026. AI assistance was used for editing and the introductory framing. The author writes for Lisar Connect and is Manager of MONTAZERI COMPUTERS & REQUISITES TRADING CO. L.L.C.

Use this checklist when a call is rough while the VPN client shows Connected. Its purpose is to isolate the next useful observation without treating the most recent configuration change as proof of the cause.

Video calls are demanding, and when one goes poorly it's tempting to pin it on whatever changed most recently — often the VPN. But call quality depends on a whole set of factors, and a VPN is one of them, not the whole story. This article sets realistic expectations for using a VPN during video calls and gives a calm order for troubleshooting when a call isn't going well.

Up front, the honest framing: this article doesn't claim a VPN makes calls better, faster, or more stable. It explains how a VPN fits into the many things that shape a call, so your expectations and your troubleshooting both land in the right place.

What actually shapes a video call

A video call's quality is the product of many factors working together. Your network's quality and how busy it is at that moment. The stability of your Wi-Fi, or whether you're on a marginal signal. How much your device is doing — a loaded machine handles video differently than an idle one. The latency and path your connection takes. And the meeting platform's own behavior, servers, and current conditions, which are entirely outside your setup.

A VPN adds one more factor to that set: your traffic takes the VPN's path. It joins the crowd rather than overriding it — which is exactly why call quality can't be attributed to the VPN alone, in either direction.

A calm troubleshooting order for rough calls

When a call is going badly, work through the factors in a sensible order rather than changing everything at once:

Start with the basics that matter most. Is your Wi-Fi signal solid, or are you on a marginal spot? Is your device overloaded with other work? These local factors shape calls heavily and are practical early checks: moving closer to the router or closing unnecessary heavy apps may help.

Check whether it's the platform. Meeting platforms have their own outages and busy periods. If calls are rough across the board, the platform's own status is worth a look before assuming anything local — it may not be your setup at all.

Consider your network at this moment. Networks get congested, especially at peak times. A rough call on a busy network may be about that moment; testing at another time or on another network helps separate a one-off from a pattern.

Then consider the VPN as one factor. If you're troubleshooting methodically, you can observe how a call behaves as one variable among the others — for an OpenVPN-based Lisar setup, verify the intended current profile and supported client. Re-download only when the profile evidence warrants it; a current profile does not rule out routing, client, or service issues. Change one thing at a time, so you can actually tell what affected what.

Remember what you don't control. The other participants' connections, the platform's servers, and the wider internet between you all affect a call and sit outside your setup entirely. Some call quality simply isn't yours to fix.

Realistic expectations, stated plainly

The honest set of expectations looks like this. A VPN is one factor in call quality, not the determining one. It does not guarantee faster, smoother, or more stable calls — nor does it promise any particular call will work a certain way, since too much of the picture (the platform, the other participants, the moment's network conditions) is outside any one setup's control. And not every network or situation will handle a demanding video call the same way.

What you can do is control your own side sensibly: a solid local connection, a device that isn't overloaded, a methodical troubleshooting order, and realistic expectations about the parts that aren't yours. That's the productive version of "using a VPN during video calls."

Use the meeting platform’s own diagnostics

Google Meet’s troubleshooting guide covers local load and connectivity; it also notes that a VPN’s additional route can delay media.

Microsoft Teams Call health exposes roundtrip time, packet loss and jitter. These observations help describe a call problem; they do not, by themselves, locate its cause.

Keep required company controls in place. Any comparison that changes the VPN route should follow the device and network owner’s approved process; do not disable required protection just to run a test.

Frequently asked questions

Will a VPN make my video calls better or more stable?
This article makes no such claim. A VPN is one factor in call quality among many — your network, Wi-Fi, device load, and the meeting platform all matter too. It doesn't act as a control knob over calls; its effect depends on all the other factors around it.

My video calls are rough while connected — is the VPN the cause?
Not necessarily. Call quality depends on many things, and the VPN is one factor, not the whole story. Check the basics first — Wi-Fi signal, device load — then the platform's status, then your network at that moment, before treating the VPN as the cause.

Does a VPN work with every meeting platform and network for calls?
Not every network or situation handles a demanding video call the same way, and platforms have their own behavior and conditions. Rather than assuming universal compatibility, troubleshoot methodically and keep expectations realistic about the parts outside your setup.

Handling a Cold-Starting Android Backend

Thu, 08 Oct 2026 03:44:20 +0000

When an application backend sleeps between requests or takes time to start, an Android app can mistake a temporary cold start for a permanent outage. The opposite failure is also common: a loading spinner retries forever and gives the user no clear way forward. How should an Android app handle an unavailable or cold-starting backend without showing an infinite startup spinner? For a related implementation, see Viewmodel Partial Success Refresh Failure.

The solution is to treat startup health checks as a finite state machine rather than an endless loop. By performing a single pass across configured endpoint candidates during launch, the application can quickly determine if the service is reachable. If the backend fails to respond, the app moves to an explicit unavailable state instead of locking the user into a permanent loading loop. When the user chooses to try again, an explicit retry action refreshes the remote configuration and checks again on a fixed interval, bounded by a visible deadline.

The Startup State Machine and Endpoint Checks

A robust mobile architecture separates initial startup discovery from active user sessions. During the first launch phase, the ViewModel checks configured base URLs once and selects the first healthy endpoint. If none of the candidates respond within the initial pass, the UI exposes a distinct unavailable state. For a related implementation, see To Robust Viewmodel Unit Tests.

This design prevents wasted network traffic and gives the user immediate clarity. Instead of guessing whether the application is frozen or broken, the user sees that the backend is currently offline. The application can distinguish between ordinary unavailability, maintenance modes, and configuration mismatches by evaluating response codes and payload flags.

Bounded Retry with Cancellation

When a cold-starting backend requires a moment to wake up, a manual retry mechanism gives users control without risking runaway resource consumption. The implementation uses a fixed two-second interval and a 75-second total deadline. These specific values correspond to the backend cold-start profile and are not universal defaults.

To prevent overlapping network calls, every new check cancels the previous coroutine job. This cancellation guarantee ensures that if a user triggers multiple retries or if configuration changes mid-check, obsolete requests do not continue running in the background.

class BackendRetryViewModel : ViewModel() {
    private var retryJob: Job? = null

    fun startBoundedRetry() {
        retryJob?.cancel()
        retryJob = viewModelScope.launch {
            val startTime = System.currentTimeMillis()
            while (System.currentTimeMillis() - startTime < 75_000) {
                if (checkHealth()) {
                    _uiState.value = UiState.Ready
                    return@launch
                }
                delay(2_000)
            }
            _uiState.value = UiState.Unavailable
        }
    }

    private suspend fun checkHealth(): Boolean {
        // Perform lightweight health endpoint check
        return false
    }
}

Testing Failure and Recovery

Verifying timeout and recovery logic requires deterministic test execution. Unit tests must cover the initial healthy endpoint selection, the transition to the unavailable state after all candidates fail, the forced configuration refresh on manual retry, and the successful recovery when a later attempt succeeds. Using virtual time control in coroutine tests allows developers to simulate the 75-second deadline and the two-second intervals instantly without slowing down the test suite.

Adapting Retry Strategies for Production

While a fixed interval and a manual trigger work well for predictable cold starts, production systems often require more sophisticated patterns. Developers should consider exponential backoff, jitter, and provider Retry-After headers when dealing with public APIs or heavily loaded microservices. Evaluating connectivity classification helps determine whether a retry should be attempted at all when the device is offline or on a metered connection.

Conclusion for Resilient Startup Flows

Designing a resilient mobile startup flow means balancing persistence with user experience. By implementing a finite health-check pass, offering a bounded manual retry, and cancelling superseded requests, you protect both the client application and the backend service from unnecessary strain. Grounding your retry intervals in actual service behavior rather than guesswork ensures a predictable experience when services wake up.

Diagnosing DNS Filtering Delays Without Resetting the Network

Wed, 07 Oct 2026 08:33:32 +0000

When a filtering change appears to have no effect, waiting is useful only after you know which setting and resolver the client is using. This checklist keeps the diagnosis focused.

Adapted with permission from the original Lisar article by Mohammad Hesameddin Montazerilisar, published July 9, 2026 and updated September 27, 2026. AI assisted editing, platform-specific framing, and the documentation note; the substantive source guidance is human-authored.

A DNS change may not be visible immediately because a device, browser or resolver still has an earlier answer cached. Caching is one possible explanation, not proof that a configuration is correct or that waiting will resolve the problem.

What DNS caching retains

DNS translates a domain name into records a client can use. Cached records are normally reusable for their time to live (TTL). The DNS specification describes this caching model. There is no single waiting period that fits every domain, resolver and application.

DNS cache is different from downloaded page content and an existing network connection. A page can keep displaying an already-loaded ad after DNS settings change. A running app may reuse an established connection without performing another lookup.

Check the setting before blaming the cache

Confirm the profile's active plan and whether DNS AdBlock is included.
Confirm the intended VPN profile is connected.
Identify the domain or application and note the time of the change.
Check whether the browser or device uses a separate secure-DNS resolver.
Compare a fresh request under the same conditions after allowing the relevant cache time to pass.

A browser using another resolver can show different results even after its cache expires. A changed setting on one profile does not establish that another device or profile has the same configuration.

For a documented browser example, Mozilla describes different DNS-over-HTTPS protection modes in Firefox. Default protection can disable secure DNS when a VPN or enterprise policy is active, while other modes use the selected provider differently. Read the active mode and policy; do not assume every browser sends every lookup to the same resolver.

Why devices disagree

Devices may hold answers obtained at different times or use different resolvers, clients and network routes. A new result on one device and an old result on another can be consistent with caching, but the difference is not enough to diagnose caching by itself.

Keep the comparison narrow: same destination, intended profile and network where possible. Record browser secure-DNS and device DNS settings without changing managed policies.

Do you need to restart?

Usually start by confirming the applied settings and opening a fresh request. Reopening an application or restarting a device may clear some local state, but it does not clear an upstream resolver's cache or guarantee a different answer. Save work before any restart.

A full network reset, client reinstall or router restart is not a routine first step for a suspected DNS cache delay. If a local cache flush is specifically needed, use the operating system's documented procedure; a managed device or network may require its administrator.

If nothing changes

Report the domain, time, device, client, profile entitlement, network and the expected versus actual result to the service support team. Do not send your complete profile or credentials. Check whether the issue is actually an ad served from the same allowed domain: DNS filtering cannot separate that ad from the content by domain alone.

Frequently asked questions

How long should I wait? There is no universal delay. The relevant TTL, resolver behavior and application state matter.

Will restarting clear every DNS cache? No. It may affect local state, but upstream caches and application behavior are separate.

Does an unchanged result mean the setting failed? Not necessarily. Check whether it was applied, which resolver is used and whether an old answer or existing connection is being reused.

Can DNS AdBlock remove an ad already on screen? No. It affects relevant lookups; it does not edit content that has already loaded.

Original author: Mohammad Hesameddin Montazerilisar, technical author for Lisar Connect and Manager of MONTAZERI COMPUTERS & REQUISITES TRADING CO. L.L.C, which develops and operates Lisar Connect.

Analyzing TP-Link Tapo Protocol Using Wireshark

Wed, 07 Oct 2026 05:48:40 +0000

Introduction

Wireshark dissector for a proprietary protocol found on TP-Link Tapo cameras, dissecting device discovery packets on ports UDP/20002 and UDP/20004, as well as control and media stream packets on port TCP/8800 and keep-alive packets on port TCP/8001. Tested on TP-Link Tapo C100 IP camera.

While trying to understand how my personal accounts and personal data is being secured, I've done some research on TP-Link's Tapo Android application as well (it includes analysis of HTTP request signature and termID building processes), which can be found by following this link to a Github repo.

Filters

The following filters are programmed for this Tapo protocol dissector:

Port	Packet Type	Field Name	Description
UDP/20002	Device discovery packet	tapo.header	Full header, saved as raw bytes
UDP/20002	Device discovery packet	tapo.version	Packet version
UDP/20002	Device discovery packet	tapo.type	Packet type
UDP/20002	Device discovery packet	tapo.opcode	Operation code for current message
UDP/20002	Device discovery packet	tapo.payload_length	Payload length
UDP/20002	Device discovery packet	tapo.flags	Flags for current message
UDP/20002	Device discovery packet	tapo.align	Extra value for struct alignment
UDP/20002	Device discovery packet	tapo.serial_number	Serial number
UDP/20002	Device discovery packet	tapo.checksum	Cheksum
UDP/20002	Device discovery packet	tapo.data	JSON payload
UDP/20002	Device discovery packet	tapo.binary	Discovery packet + binary data
TCP/8800	Contol/media packet	tapo.device_stream_boundary	Device stream boundary
TCP/8800	Contol/media packet	tapo.content_type	Content Type
TCP/8800	Contol/media packet	tapo.content_length	Content Length
TCP/8800	Contol/media packet	tapo.session_id	Session ID
TCP/8800	Contol/media packet	tapo.encrypted	Payload encryption flag
TCP/8001	Keep-alive packet	tapo.data	JSON payload

Device Discovery Packets

Ports UDP/20002 and UDP/20004 are used with configuration and cryptography-related information being sent.

Header Structure

A writeup on command injection vulnerability within tdpServer daemon that listens on port UDP/200002, as well as a writeup on remote code execution (RCE) vulnerability found in the TP-Link AC1750 Smart Wi-Fi router, describe that a device discovery packet has 16 bytes long header with it's fields defined as follows:

The fields are identified as follows:

Byte 1: Packet version.
Byte 2: Packet type.
Bytes 3-4: Packet opcode.
Bytes 5-6: Packet payload length.
Byte 7: Packet flags.
Byte 8: Struct alignment.
Bytes 9-12: Serial Number.
Bytes 13-16: Checksum.

Below is the header's representation in Wireshark:

More information about header structure of the tapo device discovery packet can be found on this Stack Overflow discussion thread.

Payloads

Observed payloads include:

Device configuration messages, some data encrypted with AES key:

{
  "error_code": 0,
  "result": {
    "device_id": "REDACTED",
    "device_name": "Tapo C100",
    "device_type": "SMART.IPCAMERA",
    "device_model": "C100",
    "ip": "REDACTED",
    "mac": "REDACTED",
    "hardware_version": "4.0",
    "firmware_version": "1.1.21 Build 220511 Rel.42882n(4555)",
    "factory_default": false,
    "mgt_encrypt_schm": {
      "is_support_https": true
    },
    "encrypt_info": {
      "sym_schm": "AES",
      "key": "REDACTED",
      "data": "REDACTED"
    }
  }
}

Public RSA key:

{
  "params": {
    "rsa_key": "-----BEGIN PUBLIC KEY-----\\nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvzPNrLCSw3Rqf+AKwla2\\nntENZ+P4UUwGDzwvSc5HyJIYkY5+aQ8tpdQAO6NfN1JlVAUm94gxH5cw9s+xGgok\\nusbhFCHvMFp2g0CxvFg1P225+fq8Hmqqm9JN/ZkL2qwR4to6yvn256IqUxzmwKi8\\nFiX60VmAkmeJDOy8XGcN8ch385T9/sX1KyKZNxzX4z5xJEOlwcr5ZdhUeOmB6dbF\\njFF8GliOKSZdE01GVgeZPqJA21/8EQa1yJy8v31o+NNRd3QJaWjIzFqjGs1sl+Zj\\niPggKWcR/LqGt8Dd031velv2gVgmyBIjqi779cxns8IA5zYsvJbkxm0pFr3CU3GZ\\nYQIDAQAB\\n-----END PUBLIC
KEY-----\\n"
  }
}

Control and Media Packets

A proprietary protocol that manages JSON control messages and encrypted media (audio + video) streams runs on port TCP/8800.

Header Structure

Header is formed from the first 28 bytes of a control and media packet. Fields are text based rather than byte-based:

Field Name	Description
----device-stream-boundary--	Every control/media packet starts with this text as a start boundary
Content-Type:	`application/json` for JSON payloads and `video/mp2t` for video stream
Content-Length:	Length of a single message
X-Session-Id:	ID of a current session
X-If-Encrypt:	Payload encryption flag; 0 - unencrypted, 1 - encrypted

Payloads

Payloads of this protocol include JSON-formatted stream information and encrypted video stream with a type of mp2t.

Video stream request:

{
  "params": {
    "preview": {
      "audio": [
        "default"
      ],
      "audio_config": {
        "encode_type": "G711alaw",
        "sample_rate": "8"
      },
      "channels": [
        0
      ],
      "deviceId": "REDACTED",
      "resolutions": [
        "HD"
      ],
      "track_id": "REDACTED"
    },
    "method": "get"
  },
  "seq": 1,
  "type": "request"
}

Response on success:

{
  "type": "response",
  "seq": 1,
  "params": {
    "error_code": 0,
    "session_id": "1"
  }
}

Channel lens mask info:

{
  "type": "notification",
  "params": {
    "event_type": "channel_lens_mask_info",
    "channels": 0,
    "enabled": "off"
  }
}

Channel resolution info:

{
  "type": "notification",
  "params": {
    "event_type": "channel_resolution_info",
    "channels": 0,
    "resolution": "1280*720"
  }
}

How to Identify the Intended VPN Profile When Client Entries Look Alike

Mon, 05 Oct 2026 08:35:05 +0000

A VPN client can hold several profiles with nearly identical labels. If the selected entry is wrong, even a careful connection test may describe the wrong configuration. Start by resolving the profile identity through its source, assignment, and intended use.

Adapted with permission from the original Lisar article by Mohammad Hesameddin Montazerilisar, published July 10, 2026 and updated September 27, 2026. AI assisted the editing, platform-specific framing, and reference notes; the substantive source guidance is human-authored.

This article explains how look-alike profiles accumulate in a client, why connecting to the wrong one is so misleading, and how to identify the intended profile using things you can actually verify — without casually clearing entries, guessing your way through them, or sharing them around.

How you end up with look-alike profiles

Duplicate-looking entries pile up for ordinary reasons. You might import a profile more than once, keep an older download alongside a newer one, or receive files whose names are similar enough that the client shows near-identical entries. Profiles intended for different devices, different people, or different purposes can also sit side by side and look alike. None of this means anything went wrong — it's just what happens when several imports accumulate over time, and the client shows them all without knowing which you consider current.

The result is a list where the intended profile isn't obvious, which is the problem worth solving.

Why the wrong profile produces misleading results

The reason this matters is that connecting to the wrong profile quietly corrupts your troubleshooting. If you're using an entry that isn't the one meant for your situation, whatever you observe afterward may be telling you about that entry rather than about any real problem — so you can spend time chasing an issue that only exists because of the profile you picked. Getting the intended profile straight first means anything you notice afterward is actually informative.

A profile name alone doesn't prove much

It's tempting to trust the name, but a profile's name on its own doesn't establish that it's the right one, that it's current, that it belongs to you, or that it's safe to rely on. Names can be similar, generic, or carried over from an older copy, so treating the label as proof is exactly how the wrong entry gets used. The name is a hint, not evidence — what settles it is the verifiable information behind the entry, which is where to look instead.

Identify the intended profile by what you can verify

Rather than guessing, identify the intended profile by details you can actually confirm. Two are especially useful.

Import date and source

When did this entry come from, and where did it come from? A known import date and trusted source help identify an entry, but a newer download date alone does not prove that it is the current assigned revision. If you're not sure when or where an entry came from, that uncertainty is itself a signal — so confirm the intended revision with your access owner or authorized source before importing another copy.

Assignment and intended use

Who and what is this profile for? Profiles can be assigned to particular devices, people, or purposes, so the intended one is the profile assigned to you for the use you have in mind. If you can't tell which entry that is, that's a question for whoever manages your access rather than something to resolve by trying entries at random. Notably, the fact that an entry exists in your client doesn't by itself mean it's the one assigned to you.

A small habit prevents most of this: when you import a profile, note its date, its source, what it's assigned to, and its intended use. That short record turns a list of look-alikes into a list you can actually read.

Coordinate with whoever manages your access

When you genuinely can't tell which profile is intended — or you're unsure whether an entry is even meant for you — the right move is to check with the person or team responsible for your access, not to connect to entries at random to see what happens. Trying profiles that aren't assigned to you isn't a good way to sort out the list; it can produce misleading results and it isn't the intended use of someone else's assigned access. A quick question to your access owner is simpler and cleaner than trial and error.

Keep client entries aligned with organized source files

Finally, the entries in your client are easiest to keep straight when they match an organized set of source files. If your downloaded profile files are tidy — clearly named, one current copy, old copies cleared once the current one is confirmed — then the entries in your client are far easier to reconcile against them. The two go together: organized files on disk make organized entries in the client. Keeping both aligned, rather than clearing entries on a hunch, is the calm way to keep the list readable — and if an entry does need clearing, that's a decision to make deliberately once you've confirmed which one is current, not a guess.

What the client documentation can establish

OpenVPN Connect's troubleshooting FAQ explains that it supports multiple profiles and may add numbered suffixes to colliding profile names. That helps explain a look-alike list; the suffix is not proof of an authorized assignment or a newer access revision. Import behavior can depend on the client and import route, so check the documentation for the version you use.

The official profile editing guide distinguishes a display name from parameters such as a server override. Where the approved setup permits a clearer display label, use it only after confirming the entry. Do not change server, proxy, credentials, or configuration content just to make names easier to recognize.

Keep any reconciliation note free of passwords, private keys, certificates, and profile contents. A non-secret label, delivery date, intended device or user, and access owner's confirmation are enough to make the next troubleshooting result more meaningful.

A practical check before the next connection

Look-alike profiles accumulate from repeated imports, old and new files, and similar names.
Connecting to the wrong profile produces misleading troubleshooting results.
A profile name alone doesn't prove it's the right, current, owned, or safe entry.
Identify the intended profile by verifiable details: import date, source, assignment, and intended use.
When unsure, coordinate with whoever manages your access instead of trying entries at random.
Keep client entries aligned with an organized set of source files rather than clearing them on a hunch.

Mohammad Hesameddin Montazerilisar is the technical author for Lisar Connect and Manager of MONTAZERI COMPUTERS & REQUISITES TRADING CO. L.L.C, which develops and operates Lisar Connect. This guidance does not authorize access through another person's assigned profile or changes to managed-device policy.

A Controlled Checklist for VPN Problems After an Operating-System Update

Sun, 04 Oct 2026 08:20:04 +0000

A VPN setup that behaves differently after an operating-system update needs a controlled comparison. The profile may be unchanged while the client environment, permissions, or network behavior has changed. Identify the failing stage before replacing files or changing several settings.

Adapted with permission from the original Lisar article by Mohammad Hesameddin Montazerilisar, published July 10, 2026 and updated July 11, 2026. AI assisted the editing, platform-specific framing, and reference notes; the substantive source guidance is human-authored.

That does not mean every update causes a VPN problem. It means “the profile did not change” is not the same as “nothing relevant changed.” A calm comparison of before and after is more useful than immediately replacing the profile or changing several settings.

The profile can stay the same while the environment changes

A profile is only one part of the connection. The full path includes:

The operating system
The compatible VPN client
System permission for the VPN configuration
The device's network connection
The assigned profile and its current access state

An update can affect the first three items without altering the downloaded file. That is why a previously working profile may behave differently after the device restarts into a newer system version.

Keep the distinction clear: the update is a possible trigger, not proof of the cause.

Permissions may be requested again

After a system, client, or management change, you may encounter a permission prompt that did not appear during recent connections. Check the actual requesting client and current device policy; the timing alone does not establish which change caused the prompt.

Treat the prompt as a new decision. Confirm that:

You opened the intended compatible client.
You are using the expected assigned profile.
The system prompt names the client you intended to use.
You are authorized to add or use a VPN configuration on the device.

On a managed device, the organization may control the permission. Do not attempt to work around a policy restriction.

Networking behavior can shift

System updates can change network handling at a broad level. Examples include:

How the device transitions between Wi-Fi and mobile data
How it resumes connectivity after sleep or restart
How DNS settings interact with the active connection
How local-network access is handled
How status is displayed when connectivity changes

These are categories, not promises about a specific device. The actual change depends on the operating system, client, device policy, and network.

If the issue appears only on one network after the update, keep network-specific causes in the comparison. If it appears on every allowed network tested, the device or client becomes a stronger area to examine.

Client compatibility matters

The installed VPN client may also need to support the updated operating system. Check the client's official compatibility information and version rather than assuming the existing installation is current.

A client update and a profile update are separate things:

A client update changes the application that reads and uses profiles.
An operating-system update changes the environment where the client runs.
A profile update changes the connection instructions supplied to the client.

Do not replace one merely because another changed. First identify which layer is showing the problem.

For a concrete client check, use the OpenVPN Connect release notes for the relevant operating system. Compare the installed client with its documented changes and supported environment. A release note is evidence about that client version, not proof that it caused your particular failure.

Background and power rules may change

Mobile and laptop operating systems manage background activity and power use. An update may change default behavior or ask the user to confirm permissions again.

The visible symptom might be a connection that does not resume as expected after the device sleeps, changes networks, or remains idle. This can resemble a profile issue even when the profile imported correctly.

Use the client and operating-system documentation for the specific device. Avoid copying device-specific steps from an unrelated operating system or client version.

For example, the Android VPN documentation separates the system-managed VPN service lifecycle from the client's responsibility for establishing the gateway connection. It also describes background-service restrictions and settings that can block non-VPN traffic. These distinctions explain why startup, background operation, and a usable connection need separate observations. They do not establish that an unspecified OS update reset a setting or damaged a profile.

A controlled after-update checklist

Use this sequence:

Confirm ordinary internet access without the VPN only where device policy permits it. If required VPN settings block non-VPN traffic, use the approved administrator test instead of disabling the policy.
Record the operating-system version and update date.
Record the VPN client name and version.
Confirm that the intended profile is still present and identified correctly.
Note whether the failure occurs at import, permission, connection, reconnection, or after connection.
Review any new system permission prompt carefully.
Test the same setup on one other allowed network when appropriate.
Record the exact result before making another change.

This process preserves the evidence. It also prevents duplicate profile entries created by repeatedly importing the same file without knowing whether import was the issue.

Managed devices need policy-aware handling

Organization-managed devices can receive an operating-system update and a policy change at nearly the same time. The user may not be able to see which one altered the behavior.

Record both possibilities. Ask the responsible administrator whether the supported client, device policy, or VPN configuration process changed. Do not try to override management controls or use an unapproved client.

A profile that works on a personal device does not prove that the same workflow is permitted on a managed device.

When the update is only a coincidence

The timing may be coincidental. Around the same time, any of these may also have changed:

The network
The client version
The assigned profile
Access validity
Device date and time
Captive-portal state

That is why a simple timeline matters. Record the last successful connection, the update time, the first failure, and any other changes. If the first failure started before the update, the update is less likely to be the trigger.

Keep the comparison useful

An operating-system update can change VPN behavior without changing the profile file. Permissions, networking, background rules, status display, and client compatibility may all be involved. Compare the exact before-and-after state, keep tests controlled, and follow organization policy on managed devices.

Mohammad Hesameddin Montazerilisar is Technical Author for Lisar Connect and Manager of MONTAZERI COMPUTERS & REQUISITES TRADING CO. L.L.C. This article is general troubleshooting guidance, not a report of a tested device incident or a product-performance claim.

I wrote bi-directional tcp congestion control... and survived!

Sun, 04 Oct 2026 07:11:48 +0000

I'm back again after a loong break but this time I have done a lot of things apart from what I said in the last blog (obviously 🙃).

This time I'll be discussing on how I wrote the logic for using TCP in an event loop even though it is a stream oriented protocol. So my idea was simple but it took a long time to come, and this time it was purely my idea — I was sleeping and suddenly I woke up in the middle of the night and my brain was like "Hey, what if we write the size of the packet in it?" and I was like "BROO, right now?"

That did not happen exactly 😂. I simply slept without acknowledging the idea and the next day I woke up and again thought for an hour and then I remembered about this idea.

So what was the idea?

The idea is that say I have my TCP packet wherein I have some fixed size data (we'll do variable size later). Now its really easy in UDP just because UDP is packet oriented which means it preserves packet boundaries meanwhile TCP does not (that's one of the reasons why it is so good!)

So how do we get this amazing UDP property from TCP? The idea is simple, write down the packet size on the packet itself.

Say you have the packet struct defined as:

struct myPacket {
    size_t packetSize;
    int someData;
    char someData2;
    // ...some more data
};

Now here, we if do sizeof(struct myPacket) we will get the answer as 16 (yes it's not 13 as I expected earlier because of compiler adding some padding to make 13 a multiple of 4 which makes it easier for the CPU to fetch the pages from memory).

And the value of the packetSize member is 16. So now picture this, you're doing

int got = read(fd, buf, ???);

Here you don't know the value you should put into your buffer since you don't know what packet is coming. But now if every packet sent by the other side (which is also your own code, atleast in my case it is 😂) has this size defined as the first member of the struct you could simply do this:

int got = read(fd, size, sizeof(int));

And once you get that, read the value of buf and figure out the packet size like this:

int size;
int got = read(fd, &size, sizeof(int));

if (size == sizeof(struct myPacket)) {
    struct myPacket *mp = malloc(size * sizeof(char));
    mp->packetSize = size;
    got = read(fd, (char *)mp + sizeof(int), size - sizeof(int));
}

Here I've written more code than needed because I wanted to make it look more "complete" 😅

What's happening here is that first we read an int from the stream. now this int contains the size of the packet (ofc, you'd need ntohs here, but I figured that'd make this more hard to read). And then you simply read the rest of the packet in a struct. Now you don't have to read the remaining data at the start of the struct hence the mp + size instead of mp alone. Now I know it would be much better and safer to use offsetof but for an example this works great.

Anyways this was when everything is great and life is simple. But sadly that ain't true (I wish it was ). So now what if the data hasn't arrived yet? I mean the member someData has arrived but someData2 is still travelling on the network. And when you demand for the entire data read does something clever, it simply blocks you. And that is not a good thing when you're in an event loop since the kernel does not know that you're doing multi threading without telling it and one such blocking call is quite deadly since the entire process goes into the blocked state until the packet is not complete.

Think about that for a second, until the entire packet arrives, no heartbeats, no voting, nothing the node can do. For the node it simply underwent time travel 😵. So we do not want to handle time glitches in a system that is already handling a thousand other things. So the kernel gives us a solution, make the read function non blocking (hurray!). I already wrote this in the previous blog but I'll anyways repeat it. So once the read function is non-blocking we have the control to what we want to do except sleeping.

So here's the thing, the Assigner I have in mind acts as a congestion control for the Gateway and the Worker and hence it looks something like this:

So if suppose the diagram was simpler with the Gateway Data (IN) going to Worker Data (OUT). Now in this case if the Gateway sends more data than what I can store (say, my TCP buffer is full as well as the buffer I allocate using malloc) but the worker is slow and hence the buffer in the workers side sending data eventually fills up and no more data can go in. To visualize it:

So here as you see the data flows in chunks, green indicates the data is there but the buffer is not yet full. Then red indicates the buffer is full and there is not space. So now to implement congestion control I need to stop the gateway when the worker's internal buffer fills up. And since we're using epoll how do we do this?

First thing we do is add the events EPOLLIN and EPOLLOUT to both the sockets along with EPOLLET. Now you'll find the descriptions in the man pages of epoll (7) but its better if I maintain the flow here. So EPOLLET simply means that if the buffer was full and now some data is removed tell me and if the buffer was empty and some data has come in tell me. It won't tell you unless the extremes change, i.e., if new data arrives and there was data previously which you forgot to read, you're basically dead meat 😂, epoll in EPOLLET mode won't tell you if something like that happens. It simply ignores that but if you're in the default mode (i.e., you don't have the flag added) you'll get a totally normal behaviour of epoll continuously waking you up when data is available.

However, in this case the best thing is to use EPOLLET with EPOLLIN and EPOLLOUT. And that is better explained with a visual 😁:

There's a ton of steps but believe me its easy once you understand it (wait for two way congestion control 😁)

Step 1: the gateway sends data and the data is stored in the internal buffer of the socket and the EPOLLIN event is triggered for the gateway socket

Step 2: the assigner reads all the data from the gateway and empties out the internal buffer and puts that data into its own buffer.

Step 3: the assigner writes that data to the internal buffer of the worker socket.

Step 4: more data comes from the gateway, and steps 1-3 repeat.

Step 5: Now the worker socket's internal buffer is full hence send returns -1 with errno set as EAGAIN. So now the assigner will simply remove the EPOLLIN event from the gateway socket. So now even if the gateway sends the data, TCP will simply not allow data to flow because its own buffer is full.

Step 6: The gateway is fast and won't stop so the gateway socket's internal socket gets full. But since the assigner does not read the data, TCP by default stops the data transfer until the data is read.

Step 7: Once the worker reads something, its EPOLLOUT event will trigger because the buffer was full and now it is not hence EPOLLOUT. So now the assigner will first empty its own buffer (not visible in the diagram since it would have introduced a lot more steps) into the workers socket. Now if only some data goes in and the send function again returns an error we don't have an option and we simply wait on the EPOLLOUT event again. But if all the data is sent from the assigner's buffer, the assigner will read more data from the gateway socket. And this newly read data will also go to the worker socket.

Step 8: This newly read data might not again be fully absorbed by the send function hence we don't change any events on the sockets.

Step 9: Now the case when we read from the gateway socket and it returns a value less than the size of the buffer we specified. This means that the gateway has stopped sending the data from the other side and the gateway socket is completely drained. Now what? We simply add the EPOLLIN event to the gateway socket. So now the gateway socket has the EPOLLIN and EPOLLOUT events attached to it.

Step 10: Now keep on feeding the worker until the assigner's buffer isn't empty. Once the assigner's buffer is also empty we simply do nothing since that is the last time the EPOLLOUT event will trigger. From then on the buffer will be at the minimum 1 byte not filled unless the gateway starts sending like a freak again 😂

So that's all the steps the visual is trying to explain. Now you should have a question that why we're using EPOLLIN and EPOLLOUT instead of using only the events which are actually needed. So the gateway never uses EPOLLOUT and the worker never uses EPOLLIN then we should keep the other events for these sockets right?

That's where the bi-directional congestion control comes into play 😁

Bi-directional Congestion Control?

So now you know how we can do congestion control in a single direction but a node will always send and receive so things are never so simple

First you can try to figure out the bi-directional congestion control mechanism yourself but I'll anyways explain it to you.

So as you see in the diagram below you have two sockets each side:

And you have to make sure congestion control in one direction does not interfere with the data flow of the other direction

Firstly let's name the sockets:

GIN - Gateway Data IN
GOUT - Gateway Data OUT
WIN - Worker Data IN
WOUT - Worker Data OUT
GTW - Gateway To Worker data flow
WTG - Worker To Gateway data flow

Note: Here GIN and GOUT are a single socket because TCP is a duplex connnection but for a better understand I have shown them separately. And the same goes for WIN and WOUT

So now if the Worker has a lot of output to send to the gateway your WIN socket will keep on throwing EPOLLIN events whenever you finish reading it. But then at the same time if the WOUT was full and you've kept only EPOLLOUT then you'll be in trouble because then you won't receive EPOLLIN.

So there is a clever strategy I developed on my own (yeah, this time no gemini brainstorming sessions 😂). You always keep EPOLLOUT on all the OUT sockets. So this means we have EPOLLOUT on WOUT and GOUT. Now you should ask:

Why meet why?

This is because having EPOLLOUT along with EPOLLET gives you a solid advantage to handling bi-directional congestion control. Firstly EPOLLOUT is only ever triggered when the socket goes from totally full to a not full state. So you won't be handling the EPOLLOUT event when some data goes out every time but only when the socket was full and not has at mininum a single byte of free space.

So now that EPOLLOUT is not going anywhere the only event we will ever add/remove is EPOLLIN (EPOLLET is the default, like EPOLLOUT it won't go anywhere 😁). So the advantage of only ever changing EPOLLIN is that if I remove the EPOLLIN from WIN and wait for GOUT's EPOLLOUT to trigger, I can still handle EPOLLIN from GIN or wait for WOUT's EPOLLOUT without having to worry about what the other side is doing.

Isn't that a great advantage? I mean for my case it works pretty well

Let's code it

So for a bi-directional congestion control mechanism I am not sure if a visual will help or just leave you confused but here it is anyways 🙃

This two way congestion control is working in a similar way to the one way congestion control except now its happening at two places simultaneously 😵

Now its easier to see this in code. So first let's assume some things:

There is a socket named w and a socket named g and in here both are TCP sockets so WIN and WOUT both are w itself and similarly GIN and GOUT both are g itself.
Both the sockets are added to a epoll loop and the loop is configured in a way that it runs either of the two functions on any event received and also passes the events down
resetEpollEvent is a function which takes in the socket and the new events to be added to the socket

So first we write the gateway handler (EPOLLIN for now):

void *handle_gateway(void *args) {
    int events = *(int *)args;
    if (events & EPOLLIN) {
        // data received on g
        int size = recv(g, buf, sizeof(buf));
        sent_size = send(w, buf, size);
        if (sent_size != size) {
            // all data was not sent, the buffer is full!
            resetEpollEvent(g, EPOLLOUT | EPOLLET);
            size_to_send = size - sent_size;
        }
    }
}

And similarly you can guess the EPOLLIN branch for the worker handler:

void *handle_worker(void *args) {
    int events = *(int *)args;
    if (events & EPOLLIN) {
        // data received on w
        int size = recv(w, buf, sizeof(buf));
        sent_size = send(g, buf, size);
        if (sent_size != size) {
            // all data was not sent, the buffer is full!
            resetEpollEvent(w, EPOLLOUT | EPOLLET);
            size_to_send = size - sent_size;
        }
    }
}

Now these were for the EPOLLIN event but now let's write the gateway to handle the EPOLLOUT event as well:

void *handle_gateway(void *args) {
    int events = *(int *)args;
    if (events & EPOLLOUT) {
        // now g can be fed some data
        int size = send(g, buf, size_to_send);
        if (size == size_to_send) {
            // all data was sent! take more and send
            int sent_size = 0;
            size = recv(w, buf, sizeof(buf));
            while (size != -1) {
                sent_size = send(g, buf, size);
                if (sent_size != size) {
                    // the buffer is full again!
                    size_to_send = size - max(sent_size, 0);
                    // here max function is implicitly declared and its purpose is to keep sent_size as a minimum 0 in cases where sent_size might become -1
                    break;
                }
                size = recv(w, buf, sizeof(buf));
            }
            if (size == -1) {
                // yay! all data was sent!
                resetEpollEvent(w, EPOLLIN | EPOLLOUT | EPOLLET);
            }
        }
        // if the size does not match what we want to send, then just keep waiting again
    }
}

I know its a bit longer code than what I wrote for EPOLLIN but I assure you it is worth the dive 😁

And now you should try writing the code for the worker's EPOLLOUT branch yourself (Hey, I'm not lazy 😑)

Apart from the EPOLLIN and EPOLLOUT events you also have 3 events to tell you that the connection is cut EPOLLRDHUP, EPOLLHUP and EPOLLERR these three together can detect almost any kind of connection cuts.

EPOLLRDHUP detects if a socket is closed from the other side of the network as in using the shutdown function which I think no one generally uses 😂. If this event occurs, your socket is writable but not readable and the writability is local, the peer won't be able to read what you wrote if it has closed its reading end.
EPOLLHUP also detects if a socket is closed from the other side but this event detects any errors from the socket and if this event happens then your socket is neither readable nor writable.
EPOLLERR detects some error that happened on the socket. Yeah that's it 😂

Now this was congestion control and tcp packet parsing but both aren't independent, you'll have to handle both together so the parsing happens on the data that comes from the data flow mechanism which also handles congestion inside itself

But now that you do know the concept this should be much easier. And yeah I struggled to come up with the idea first and then struggled more to implement it but then combining both seemed trivial once I had them independently done.

If I can do it, you can too!

— Some genius (Me 😜)

Just joking! The parsing and congestion control should mostly never overlap since congestion control is for a middleman like an assigner and parsing is for a consumer like a worker or a producer like a gateway (could be the other way round too). A consumer always consumes at its own pace and a producer produces at its own pace and hence the middleman needs congestion control.

In my case the worker (consumer) uses a blocking socket hence even if it is slow or fast does not matter since it will experience time glitches which are fine in my case.

Conclusion

I hope you did not get confused and got to learn something good from this blog but I'm happy to answer any questions you face in the chats.

Disclaimer: Meet can make mistakes, always verify with someone/something

The packet parsing was a bit trivial once I added the size member to the head of the struct. But figuring out the congestion control mechanism demanded me to look into TCP's congestion control (which was of very little help) and in general congestion control and mix them up and create a new mechanism. But then that mechanism was, I'd say, not so "good" hence I threw it in the trash and explored distributed algorithms like paxos, raft and distributed systems like bit torrent and one morning my brain wished me a "Good Morning" with this idea and I was surprised I could think of such a good mechanism. (Yeah I'm proud of my creation, for the first time though 😁)

Currently I'm also new to the distributed realm and you're a better expert than me so if you spot any mistake in my approach or anything please do let me know, I'm more than happy to recreate a new mechanism from scratch and throw this in the trash too 😂 but the new one should be worth it!

So, what's next?

Currently I'm learning some Rust cause I heard it is a harder language than C and I just want to see exactly how hard it is. I'm starting with the fundamentals and mostly using the book The Rust Programming Language which is not exactly a book but a webpage. And I think its pretty awesome since this is the first community I saw making such an amazing and deep "documentation".

And the next time I'm going to discuss on linux containers and how to use OverlayFS on the containers. Also I "might" discuss about GARP and OPFS but all depends on time 😁

Show a single Windows application window in any web browser on LAN

Sun, 04 Oct 2026 05:51:45 +0000

Ever needed to show one app window on a tablet without any remote-desktop software?

I built WindowStream for exactly that, and Ive just open-sourced it.

Its a small Windows tray app that streams a chosen window as MJPEG over HTTP on your local network. On the tablet or other PC you just open a browser: nothing to install, and its strictly view-only.

What Im happy with:

Any modern browser works as the viewer (Android, iOS, another PC), with pinch-zoom, panning and fullscreen.
Two capture modes: a screen copy, or PrintWindow, which keeps streaming the window even when other windows cover it.
Light on resources: a frame is encoded only when the picture has changed, and JPEG encoding goes through libjpeg-turbo.
Starts with Windows and finds the window again even if its title changes.
English and Russian interface, a single-exe build, unit tests, and user manuals in three languages. Python, MIT licensed.

One caveat: there is no password or encryption, so its meant for trusted networks only, and the docs say so clearly.

Code, a release with the ready-made exe, and documentation: https://github.com/eugenyh/WindowStream

Feedback and ideas are very welcome!

Building a Line-Rate Linux Kernel Firewall in Pure Rust with Aya and eBPF/XDP

Sat, 03 Oct 2026 13:29:33 +0000

Volumetric Distributed Denial of Service (DDoS) and transport-layer flooding attacks pose an existential challenge to modern cloud infrastructure, edge gateways, and container workloads.

Conventional Linux packet filtering utilities such as Netfilter (iptables and nftables) evaluate incoming frames only after the kernel has allocated a socket buffer (sk_buff) descriptor and scheduled softirq processing through the core TCP/IP stack. Under multi-gigabit line-rate flood conditions (millions of packets per second), the operating system spends the vast majority of its CPU cycles simply allocating and freeing sk_buff memory metadata, triggering kernel starvation and packet drop bottlenecks even before firewall rules are evaluated.

To address this fundamental OS-level bottleneck, I built xdp-guard: a production-grade, memory-safe in-kernel defense engine and per-IP rate limiter implemented strictly in Pure Rust using the Aya eBPF framework.

Why eBPF / XDP at the Driver Layer?

The eXpress Data Path (XDP) provides a programmable, bare-metal packet processing execution hook directly inside the Network Interface Card (NIC) driver subsystem before any memory descriptor allocation occurs.

Conventional Path:
[NIC RX] -> [IRQ / SoftIRQ] -> [Allocate sk_buff] -> [Netfilter/iptables] -> [Socket / App]
                                      ^
                           Severe CPU Allocation Overhead

xdp-guard Path:
[NIC RX] -> [eBPF / XDP Driver Hook] ---> (Match Blocklist) ---> [ XDP_DROP ] (Near-Zero CPU)
                             |
                      (Match Allowlist)
                             |
                             v
                   [ Pass to OS Stack ]

When hostile or unapproved packets are identified, returning XDP_DROP causes the network driver to immediately recycle the packet ring buffer without allocating a single byte of kernel socket memory.

Architectural Highlights

1. Zero C Dependencies (Pure Rust)

Traditional eBPF tools rely heavily on C toolchains (clang, llvm, libbpf). xdp-guard is built entirely in Rust from the user-space management CLI down to the no_std kernel eBPF bytecode using Aya.

2. Strict 64-Bit Memory Boundary Alignments

To ensure safe zero-copy communication across the kernel-userspace boundary, shared structures use explicit padding fields to guarantee 8-byte alignment:

#[repr(C)]
#[derive(Clone, Copy, Debug)]
pub struct RuleValue {
    pub action: u32,       // 0 = Pass, 1 = Drop
    pub _pad: u32,         // Explicit 4-byte padding for 8-byte boundary
    pub created_at: u64,   // Monotonic timestamp
    pub ttl_secs: u64,     // Time-to-live expiration
}

The presence of _pad: u32 is critical: it prevents architecture-specific compiler padding discrepancies and satisfies the Linux Kernel BPF Verifier.

3. Dynamic BPF Virtual Filesystem (bpffs) Synchronization

Firewall rules (blocklist and allowlist) are dynamically synchronized using pinned BPF hash maps located in /sys/fs/bpf/xdp_guard. Rules can be inserted or deleted instantaneously from the CLI without tearing down network interfaces or interrupting traffic flows.

4. In-Kernel Token-Bucket Rate Limiter

In addition to static blocklists, xdp-guard embeds a stateful token-bucket rate limiter directly in kernel space. Monotonic arrival intervals ($\Delta t = t{now} - t{last}$) are computed using nanosecond bpf_ktime_get_ns() clocks, discarding over-limit burst floods at line-rate.

Empirical Verification: Real Linux Kernel Telemetry

To validate xdp-guard under realistic operating conditions, we set up an automated Linux network namespace testbed over virtual ethernet (veth) pairs (xdp_client at 10.10.0.2 and xdp_server at 10.10.0.1).

Telemetry streamed directly from the kernel STATS_MAP array demonstrated instantaneous 100.00% packet mitigation upon inserting an attacker IP into the kernel blocklist, followed by zero-loss recovery:

TIMESTAMP            PASSED (PKTS)   DROPPED (PKTS)  DROP RATIO     
-----------------------------------------------------------------
09:56:56 | Pass: 1        (30.2 KB) | Drop: 0        (0 B)   | Ratio: 0.00%
[!] Inserting IP 10.10.0.2 into BLOCKLIST_MAP... [SUCCESS]
09:56:57 | Pass: 0        (30.2 KB) | Drop: 1        (98 B)  | Ratio: 100.00%
09:56:58 | Pass: 0        (30.2 KB) | Drop: 1        (196 B) | Ratio: 100.00%
09:56:59 | Pass: 0        (30.2 KB) | Drop: 1        (294 B) | Ratio: 100.00%
...
09:57:55 | Pass: 0        (30.2 KB) | Drop: 1        (5.7 KB)| Ratio: 100.00%
[!] Removing IP 10.10.0.2 from BLOCKLIST_MAP... [SUCCESS]
09:57:56 | Pass: 1        (30.3 KB) | Drop: 0        (5.7 KB)| Ratio: 0.00%
09:57:57 | Pass: 1        (30.4 KB) | Drop: 0        (5.7 KB)| Ratio: 0.00%

Every single drop occurred directly within the NIC driver hook, requiring zero kernel TCP/IP stack overhead.

Source Code & Research Paper

The complete project, documentation, and formal research paper are fully open-source:

GitHub Repository: https://github.com/rahadbhuiya/xdp-guard
Citable Zenodo DOI: 10.5281/zenodo.23120995
Automated CI: Continuous testing across Rust Stable and Nightly LLVM targets via GitHub Actions.

If you are working on Linux kernel systems, eBPF, or Rust networking, I would love to hear your thoughts, feedback, or suggestions!

A Practical Response Checklist for Account Alerts After Network Changes

Sat, 03 Oct 2026 08:29:22 +0000

Cover: Conceptual illustration; may be AI-generated. Original creation method is unverified. The alert, padlock and location symbols are illustrative, not a real account incident, current application screenshot or security test. Image from the Lisar Website archive.

Original author: Mohammad Hesameddin Montazerilisar, Technical Author for Lisar Connect and Manager of MONTAZERI COMPUTERS & REQUISITES TRADING CO. L.L.C. Adapted from the original Lisar guide, published July 10, 2026 and updated July 11, 2026.

Editorial disclosure: The substantive guidance comes from the human-authored source. AI assistance was used for editing, platform framing and source checking. This is explanatory guidance, not a report of a new device or VPN test.

A developer switching between home, mobile and office networks may encounter an account alert. Before editing a VPN profile, establish whether the activity was expected. This checklist keeps account verification with the service that owns it and reserves connection notes for a useful, non-sensitive support timeline.

Online services may show a new-sign-in, unusual-activity, or security alert after the public IP or network changes. A VPN connection can contribute to that change, but the timing alone does not establish why the service sent an alert. Services may also evaluate device, browser, time, cookies, authentication method, sign-in history, and account behavior.

An alert should be reviewed through the service’s official account-security process. It should not be dismissed as “just the VPN,” and it should not be used as proof that the VPN caused an account restriction.

Security systems try to distinguish expected activity from activity that may require verification. A sign-in can look different when it comes from:

a new public IP;
a different network operator or country estimate;
a new device or browser;
cleared cookies;
a private-browsing session;
a different time than usual;
repeated failed sign-ins;
a changed authentication method;
a recent password or account-security change.

A network transition—home Wi-Fi to mobile data, office network to hotel Wi-Fi, or direct connection to VPN—can alter the visible IP. The service may ask for confirmation because the overall context changed.

Network change is one signal, not the whole decision

It is tempting to draw a simple conclusion: “The IP changed, therefore the alert appeared.” That may be true in some cases, but users normally cannot see the service’s complete risk model.

The same account may change networks without an alert when the device and browser are familiar. Another sign-in may trigger verification even from the usual network because the browser, cookies, password, or behavior changed.

Use cautious language. A VPN may be associated with the timing of an alert, but it does not prove why a service made a security decision.

Read the alert details before acting

Open the service directly through its known application or website rather than following an unexpected message link. Review:

sign-in time;
device or browser shown;
approximate location or IP information;
whether the session is recognized;
actions recommended by the service;
other recent account-security events.

Location labels may be based on an approximate IP database and can be inaccurate. Focus on the combination of time, device, browser, and your actual activity.

If the alert is not recognized, follow the service’s official account-security instructions. A VPN troubleshooting article should not replace that process.

When the activity was yours, complete the service’s normal verification if required. Do not attempt to bypass device confirmation, multi-factor authentication, account review, or other security controls.

When the activity was not yours:

use the service’s official security page;
review active sessions where available;
follow its account-recovery or password guidance;
preserve relevant alert details;
contact the service through its official support route if needed.

Do not share verification codes, recovery codes, tokens, cookies, or screenshots containing sensitive account information.

Avoid assuming the VPN caused every alert

Check what else changed around the same time:

Was this a new device?
Was the browser reinstalled or reset?
Were cookies cleared?
Did the operating system update?
Was the account password changed?
Did the user travel or change time zones?
Did the sign-in occur after several failed attempts?
Did the service send the alert before the VPN connection began?

A timeline prevents the VPN from becoming a catch-all explanation for unrelated account events.

Reduce avoidable confusion without bypassing controls

Users can make legitimate activity easier to understand by:

keeping device date and time correct;
using the service’s official application or website;
avoiding rapid sign-ins from several browsers during troubleshooting;
recording which network and device were used;
completing the service’s required verification;
signing out of abandoned or shared devices through approved account controls;
following employer or service policies.

Do not promise that a stable network or profile will prevent alerts. Security systems can still request verification for other reasons.

What to record for a legitimate repeated alert

If recognized activity repeatedly triggers alerts, record:

service name;
date and time;
device and browser;
whether the VPN was connected;
network type before connecting;
approximate location shown by the alert;
whether cookies or browser state changed;
verification step requested;
whether the issue occurs with the same account on another authorized network.

Share only non-sensitive details with support. Do not send authentication secrets or raw session information.

A safe response sequence

Open the service directly.
Review time, device, browser, and approximate location.
Decide whether the activity is recognized.
Complete official verification for recognized activity.
Use official account-security steps for unrecognized activity.
Build a timeline if alerts repeat.
Treat network change as one possible factor, not a proven cause.

How to interpret the alert calmly

An account alert may follow a network change, a new device, an unusual sign-in pattern, or another provider-specific signal. Read the exact message, use the platform’s official security flow, and avoid assuming the VPN is either the sole cause or a way to prevent future checks.

Use the account provider's own interpretation

Google's security-alert guidance distinguishes activity you recognize from activity that was not yours and asks you to review the sign-in details. Its device and session guidance also explains that one device may have multiple sessions and a displayed time may reflect background synchronization. These are provider-specific details: use your service's documentation instead of treating one timestamp or location label as a complete diagnosis.

Public Wi-Fi for Work Travel: A Practical VPN and Device Checklist

Fri, 02 Oct 2026 09:35:21 +0000

Cover: Conceptual illustration; may be AI-generated. Original creation method is unverified. Symbols do not represent tested security or a current application screen. Image from the Lisar Website archive.

Before working from a hotel, airport or coworking space, check the actual travel device, the VPN setup and the rules for the task. This checklist keeps tunnel coverage and device security in view.

Originally written by Mohammad Hesameddin Montazerilisar, Technical Author for Lisar Connect and Manager of MONTAZERI COMPUTERS & REQUISITES TRADING CO. L.L.C. Adapted from the human-authored Public Wi-Fi for Work Travel: What a VPN Helps With and What It Does Not, published July 1, 2026 and updated September 27, 2026. AI assistance was used for editing, platform framing and source checking; the substantive human source is retained.

Public Wi-Fi is not a controlled work environment

At the office or at home, the network may have a known owner and configuration. On public Wi-Fi, the traveler may have neither. That's not a scare story — hotel, airport, and coworking networks serve thousands of people uneventfully every day — it's a planning fact: the environment's configuration, maintenance, and other users are all outside the traveler's control and knowledge.

Treating public Wi-Fi as uncontrolled doesn't mean avoiding it. It means not extending office assumptions to it: not assuming the network is maintained, not assuming it behaves like the last one, and not assuming any single tool covers what the environment doesn't provide.

The FTC notes that widespread website encryption makes public Wi-Fi usually safe, while warning that encrypted sites can still be scams. A protected connection and a trustworthy destination are separate questions.

What a VPN can help organize on shared networks

A compatible VPN carries the traffic routed through its encrypted tunnel between the device and VPN gateway. On public Wi-Fi, this separates that covered traffic from the local network path. It also gives the traveler a prepared setup to use where the network supports it. Choose the current guide for the actual device: L2TP/IPsec where compatible and appropriate, or an OpenVPN profile with a compatible client where L2TP/IPsec is unavailable or unsuitable. Use only that person's authorized active profile and keep its connection values private.

The tunnel has a defined scope: it does not secure the destination website, fix a compromised device or force every app through the same route. Continue using HTTPS and the device controls your work requires, and confirm the active connection rather than relying on a saved profile.

What a VPN does not make safe by itself

A VPN does not make public Wi-Fi, hotel Wi-Fi, airport Wi-Fi, coworking networks, or mobile networks fully safe. It doesn't guarantee anonymity, doesn't guarantee speed, doesn't guarantee access to any service or work tool, and isn't a bypass or unblocking mechanism for whatever a network or service restricts.

It also isn't malware protection, endpoint security, or a substitute for the traveler's own habits. Device updates, safe browsing, screen awareness in shared spaces, and ordinary skepticism about unexpected prompts all still matter on public Wi-Fi — VPN or not.

Hotel, airport, coworking, and mobile networks can behave differently

Public networks aren't interchangeable. Hotel and airport networks often sit behind captive portals and their own management layers; coworking networks vary with the operator; mobile networks behave differently again. Any of them may restrict, throttle, or simply not support a given setup, and no network is guaranteed to allow or support every setup.

For planning, that means expecting variation rather than being surprised by it — and having the relevant Lisar setup guide reachable when a network behaves unlike the last one, rather than improvising changes to a working configuration.

Why setup should be checked before the trip

The worst place to discover a setup problem is the environment least suited to fixing it. Setup checked at home, on a familiar network, with the panel and guides at hand, is a routine task; the same problem in an airport, on deadline, over a captive portal, is not.

The pre-trip check is short: the setup works on the actual devices traveling, tested from a familiar network; any new device gets set up from that person's own panel profile using the relevant guide before departure, not after; and the traveler knows where the setup guides and official support live.

Company-managed devices and employer policy still apply

A managed work laptop is still managed at the airport. Device policies restricting apps, VPN profiles, certificates, and network settings travel with the device, and public Wi-Fi doesn't suspend them — nor does it suspend the employer's rules about what work happens on which networks.

VPN setup works within device policy, not around it. For work travel specifically, the employer's IT function is part of the pre-trip picture: what the device allows, and what policy expects on public networks, are their questions to answer.

Profile safety on the road

Travel is where profile-safety habits get tested, because travel is when people ask for help from odd places at odd hours. The habits stay the same: profile-specific setup information comes from the person's own Lisar panel profile, not from old screenshots or saved messages; downloaded .ovpn profile files, credentials, and profile details stay out of shared documents and chat threads; and any screenshot sent to anyone — including support — gets checked for profile-specific details first.

Shared or public computers deserve special mention for travelers: setup details don't get entered or saved on machines that aren't the traveler's own.

What to check before using public Wi-Fi for work

The working checklist, kept to planning:

Is the VPN setup tested on the actual travel devices, from a familiar network, before departure?
Are device OS and apps updated before the trip rather than over hotel Wi-Fi?
Is the device company-managed — and if so, what do its policy and the employer's network rules expect?
Does the traveler know the network may not allow or support the setup, and what the permitted fallback plan is, such as mobile data where allowed?
Are profile details kept private, with setup values obtained from the traveler's own panel and nothing entered on shared machines?
Is sensitive work matched to the environment — screen awareness in shared spaces, and judgment about what to do on which network?
Does the traveler know where the setup guides and official support live, before needing them?

A Practical VPN Access Inventory: Fields, Statuses and Update Events

Thu, 01 Oct 2026 08:36:29 +0000

Cover: Conceptual illustration; may be AI-generated. Original creation method is unverified. Image supplied from the Lisar Website article archive.

A small VPN inventory is most useful when it answers operational questions: who owns the assignment, which device it belongs to, and what changed. This guide provides fields and lifecycle statuses that a team can maintain without copying access material.

Originally written by Mohammad Hesameddin Montazerilisar, Technical Author for Lisar Connect and Manager of MONTAZERI COMPUTERS & REQUISITES TRADING CO. L.L.C. Edited republication of How to Maintain a VPN Access Inventory for a Small Team. AI assisted the editing and platform-specific presentation; the substantive guidance comes from the human-authored source.

A VPN access inventory is a simple list of who has access, which device the access is meant for, what the assignment is used for, and whether it is still current. It is not a copy of profile files and it is not a password list.

For a small team, a spreadsheet or lightweight internal table is usually enough. The value comes from keeping it accurate when people join, leave, replace a device, or receive an updated profile.

What the inventory should answer

A useful inventory lets the team answer these questions without opening profile files:

Who is the access assigned to?
Which device or router is it intended for?
What is the approved purpose?
Which profile revision is current?
Is the assignment active, awaiting setup, or no longer needed?
Who should review the record when something changes?

If the table cannot answer those questions, it is probably either too sparse or filled with the wrong kind of detail.

Use a small set of practical fields

Start with fields the team will actually maintain:

Owner — Person or approved role responsible for the assignment
Device — Laptop, phone, router, or approved device label
Purpose — Work, travel, office router, contractor access, or another approved use
Profile label — The same non-sensitive label used in the filename or client
Current revision — A date or revision such as R03
Status — Awaiting setup, active, needs review, replaced, or closed
Last checked — When the assignment was last confirmed
Notes — Short non-sensitive context or next step

That is enough for many teams. Add fields only when they solve a recurring problem.

Keep profile contents and credentials out of the inventory

The inventory is a tracking tool, not a secret store. Do not paste or attach:

.ovpn file contents;
passwords, tokens, or verification codes;
private keys or certificate data;
screenshots containing sensitive values;
billing or payment details.

A profile label such as mina-laptop-work-r03 is useful. The profile itself is not.

Update the inventory at the moment work happens

Inventories become unreliable when updates are postponed. The best time to update a record is during the event that changed it.

When someone joins

Create the assignment record before or during setup. Record the intended owner, device, purpose, and initial profile label. Once the person confirms a successful connection, update the status and last-checked date.

When a device is replaced

Do not overwrite the old device label with no explanation. Mark the old assignment as replaced or closed, then create or update the record for the new device. This keeps the history understandable without storing technical secrets.

When a profile is reissued

Update the current revision and add a short note explaining the ordinary reason, such as device replacement or updated connection information. The detailed profile content should not be copied into the inventory.

When someone leaves or no longer needs access

Mark the record for the approved offboarding process and track the resulting status. Do not assume that deleting a local file alone changes the service-side access state.

Use clear statuses instead of vague notes

A small set of status values makes the table easier to scan:

Awaiting setup — assigned but not yet confirmed on the intended device.
Active — current assignment confirmed for normal use.
Needs review — something changed or the record has not been confirmed recently.
Replaced — a newer assignment or profile revision took its place.
Closed — the assignment is no longer part of the active inventory.

Avoid statuses such as maybe, old?, or probably fine. If the team is uncertain, Needs review is clearer and gives someone a next action.

Give each record one clear owner

The owner does not need to be a full-time administrator. It can be the person using the profile, the team lead, or whoever handles setup. The important point is that someone knows they are responsible for confirming the record when a device, role, or profile changes.

For shared office equipment, assign the record to a named responsible person or role rather than leaving it as “shared” with no owner.

Review the inventory in a short, repeatable way

A lightweight review can take a few minutes:

Compare the list with the current team roster.
Check whether any devices were replaced or retired.
Confirm that the profile revision recorded as current still matches the setup notes.
Look for Awaiting setup or Needs review records that have no next step.
Confirm that shared equipment still has a named owner.
Close or update records that no longer reflect current use.

The review is about keeping the list useful, not collecting more data.

A simple example

Mina — Laptop-07 — Daily work — mina-laptop-work-r03 — Active
Sales room coordinator — Router-02 — Shared office — sales-router-office-r02 — Needs review
Contractor 7 — Phone-04 — Travel task — contractor7-phone-travel-r01 — Awaiting setup

The example identifies assignments without exposing any access material.

Frequently asked questions

Do we need special inventory software?
Not necessarily. A protected spreadsheet or internal table is usually enough for a small team, provided access is limited and someone keeps it current.

Should the inventory include every downloaded copy of a profile?
No. Track the approved assignment and current revision, not every local duplicate in a downloads folder.

Is the inventory proof that a connection is active right now?
No. It records assignment and lifecycle information. A live VPN client status is a separate signal.

How often should the list be reviewed?
Review it when people, devices, or profiles change, plus a periodic check that fits the pace of the team.

Keep the record separate from the access control

A status in the inventory is a record to maintain. It does not itself enable, disable, or verify a live VPN connection. OpenVPN documents removing a saved profile from OpenVPN Connect as a client action; follow the access administrator’s approved process for service-side changes. For broader organizational controls, the NIST SP 800-53 control catalog is a separate reference, not a certification supplied by this checklist.

Keep the inventory small, access-limited and current. Update the assignment when the work happens, and give unresolved records a clear review owner.

Reading OpenVPN Connect Import Problems Without Blind Retries

Wed, 30 Sep 2026 08:18:30 +0000

Cover: Conceptual illustration; may be AI-generated. Original creation method is unverified. Image supplied from the Lisar Website archive.

An import error is useful evidence only when it is tied to the correct stage. This guide separates file selection, download completeness, client compatibility and device permissions from the later connection attempt.

By Mohammad Hesameddin Montazerilisar, Technical Author for Lisar Connect and Manager of MONTAZERI COMPUTERS & REQUISITES TRADING CO. L.L.C. Edited republication of his human-authored Common OpenVPN Connect Import Problems and How to Read Them (published July 9, updated September 27, 2026). AI assistance was used for editing, framing and reference checks. No new hands-on test is claimed.

When importing a profile into OpenVPN Connect doesn't go smoothly, it rarely means something is seriously wrong — most import hiccups fall into a handful of recognizable categories, and knowing the categories turns "it won't work" into "ah, it's probably that one." This is a field guide to reading them calmly.

Throughout, the supported path is the same reference point: download the .ovpn file, open OpenVPN Connect, choose Upload File, import and save the profile, and connect. Most import problems are simply one of the steps in that path needing another look.

If you need the ordinary upload sequence rather than help with an error, start with the step-by-step .ovpn Upload File guide. If OpenVPN Connect says the profile failed to import, first confirm which setup stage actually failed.

If OpenVPN Connect says the profile failed to import

An import-stage failure means the profile never appears in the client's profile list after Upload File. Before trying again, note the exact error wording shown on your device — but do not paste or share the contents of the .ovpn file. Confirm that you selected the complete current .ovpn file freshly downloaded from your own Lisar Panel profile, then use a supported, current OpenVPN-compatible client and allow only the device permissions required by the setup flow.

If the profile already appears in the client, the import succeeded. Do not keep re-importing it as a blind retry; use the separate post-import connection guide to diagnose the connection stage. If the profile never appears, continue through the file, client, permission, and network checks below.

Wrong file

One straightforward category to check is the selected file: the file being imported isn't the profile file. It's easy to grab the wrong thing — a different download, a renamed file, something that isn't actually the .ovpn profile at all. If the client doesn't recognize what it's given, the first check is whether the file you selected is genuinely the .ovpn file you downloaded from your own Lisar Panel profile.

Reading it: "this doesn't look like a profile" usually means exactly that. Re-download fresh from the Panel and select that file specifically.

Incomplete or corrupted download

A profile file that didn't finish downloading — or got interrupted partway — can look present while being incomplete. Spotty connections, an interrupted transfer, or a download that was cut short all produce a file that isn't whole, and a client can't import instructions that aren't all there.

Reading it: if a file that should be fine won't import, treat the download itself as suspect. Download it again, fresh from the Panel, on a stable connection, and try importing the new copy.

Outdated profile

Sometimes the file imports but reflects an older state, because it's an old saved copy rather than a current one. Profiles have lifecycles, and a file kept from months ago may no longer match what your current profile should be.

Reading it: if you're importing from something saved earlier, that's the thing to replace. The current profile is whatever your own Lisar Panel provides now — download fresh rather than reusing an old file, and let the Panel be the source of truth.

Client behavior and versions

Clients differ in how they present the import step, and behavior can vary between versions or platforms. A screen that doesn't match a guide, an option in a different place, or a client that behaves unexpectedly can all make import feel stuck when the profile is fine.

Reading it: verify the client version and the exact import error. Even a current profile can contain an option that a particular client cannot import. Follow the guide for the actual platform and retain the original file while support checks compatibility; do not remove certificate verification to silence an error.

Device permissions

Setting up a VPN profile touches parts of a device that ask permission — and if a needed permission isn't granted, the client may be unable to complete the import or enable the connection. This is normal device behavior, not a fault: the device is asking before allowing.

Reading it: if the client indicates it needs permission to proceed, that's a device-level prompt to complete as directed, following the setup guide for that operating system. On company- or client-managed devices, what's permitted is the policy owner's call — asked first, always — and this article doesn't suggest working around any device policy.

Duplicate profiles

Importing a profile that's already present, or importing the same one twice, can produce confusion about which is which. A pile of similar-looking profiles makes it hard to tell the current one from an old attempt.

Reading it: keep it tidy. Work from a single current profile, freshly downloaded, and clear out stale duplicates so there's one obvious right answer — again following your client's own documented way of managing its profile list.

Network restrictions

Network conditions matter when downloading a profile or establishing the VPN connection. Importing a complete local file is a separate step and usually does not require contacting the VPN server. Identify which step failed before treating a network problem as an import problem.

Reading it: if things behave oddly on one network but not others, suspect the network. Complete any captive portal first, test on a network you know works, and remember that not every network will support every setup — a fallback beats fighting one uncooperative network.

Reading them together

Separate the file, import, permission and connection stages. Re-download when the copy is incomplete, wrong or confirmed outdated. If the profile is already imported, avoid repeated imports and record the connection error instead. A current file plus a clear client version and error message gives support a useful starting point.

Frequently asked questions

Why won't OpenVPN Connect recognize my profile file?
Most often the wrong file was selected, or the download didn't finish. Re-download the .ovpn file fresh from your own Lisar Panel profile on a stable connection, and select that specific file when importing.

My profile imported but something seems off — could it be outdated?
Yes, if you imported an old saved copy. Profiles have lifecycles, so a fresh download from the Panel is more reliable than a file kept from earlier. The Panel is the source of truth for your current profile.

The import screen doesn't match the guide I'm following. What now?
Client screens vary by version and platform. If the file is current and correct, follow the setup guide for your actual device and client rather than a generic one, and make sure the client is a supported, up-to-date OpenVPN-compatible client.

The client is asking for a device permission — is that a problem?
No — that's normal device behavior, asking before allowing. Complete the prompt as directed, following the setup guide for your operating system. On managed devices, what's permitted is the policy owner's call.

Import works at home but not on hotel Wi-Fi. Why?
First identify whether downloading, local-file import or connecting failed. A captive portal can prevent download or connection. If the complete file is already on the device but cannot be imported, record the import error and client version; do not assume hotel Wi-Fi caused the local parsing failure.

Why did OpenVPN Connect fail to import my profile?
The message alone does not establish one cause. Check that you selected the complete current .ovpn file from your own Lisar Panel profile, that the client is supported and current for the device, and that required device permissions are allowed. If the profile already appears in the client, import succeeded and the remaining issue is at the connection stage.

Current client references

The official OpenVPN Connect import guide documents the file-import sequence. Its troubleshooting FAQ provides client-specific checks, including referenced certificate files and profile format. Apply the instructions for your actual client and provider; do not publish a profile or private key when asking for help. References checked September 30, 2026.

Diagnosing a VPN That Connects and Then Disconnects

Tue, 29 Sep 2026 08:44:12 +0000

Cover: Conceptual illustration; may be AI-generated. Original creation method is unverified. Image supplied from the Lisar Website archive.

A connection that succeeds briefly and then drops needs a different investigation from one that never connects. Start with timing and repeatable conditions.

Originally written by Mohammad Hesameddin Montazerilisar, Technical Author for Lisar Connect and Manager of MONTAZERI COMPUTERS & REQUISITES TRADING CO. L.L.C. This is an edited republication of VPN Connects, Then Disconnects: How to Read the Pattern. AI assisted the editing and platform presentation; the example timeline is illustrative, and no connection test was performed for this article.

A VPN that reaches Connected and then drops is a different problem from a client that never completes a connection. The temporary active state is the client’s report of that moment. The useful question is therefore not only why did it disconnect? but also what happened immediately before it disconnected?

Timing, device state, and network transitions usually provide more useful evidence than repeatedly reconnecting or trying unrelated profiles.

Why a later disconnect is different from a failed connection

When the client reports Connected, the device has progressed beyond import and the initial connection attempt. A later disconnect can still have many causes, but it shifts attention toward session continuity: the underlying network may have changed, the device may have entered sleep, the client may have lost permission to continue in the background, or the access state may have changed after the initial connection.

A brief Connected status does not prove that every application was using the expected route or that the session should remain active indefinitely. It only confirms the state reported by the client at that moment.

Classify the disconnect by timing

Start by placing the behavior into one of these categories:

Immediate: the client reports Connected and returns to Disconnected within seconds.
Consistent interval: it drops after roughly the same number of minutes each time.
Device event: it drops when the screen locks, the laptop sleeps, or the device wakes.
Network event: it drops when moving between Wi-Fi and mobile data or between access points.
Application event: it appears to drop when a particular application starts heavy network activity.
Irregular: there is no repeatable timing or visible trigger.

These categories do not identify the cause by themselves, but they determine what evidence to collect next. A consistent interval is especially valuable because it suggests a repeatable policy, timeout, network behavior, or lifecycle event rather than random instability.

Identify which connection failed first

Check whether the VPN disconnected first or the device lost ordinary network access first. These two sequences lead in different directions:

Ordinary internet fails, then VPN disconnects. The underlying Wi-Fi, mobile connection, router, or captive network may be the first layer to investigate.
VPN disconnects while ordinary internet continues. Focus on the client, device background behavior, profile, access state, or a network condition specific to the VPN connection.
Both appear to fail together. Record the exact order and test again only enough to confirm the pattern.

Do not assume that a working browser after the drop means the network was stable throughout the session. Some devices reconnect to ordinary internet quickly after the VPN ends.

Account for sleep, roaming, and background limits

Phones and laptops constantly change power and network state. A phone may move from Wi-Fi to mobile data, suspend background activity, or restrict an application under battery-saving rules. A laptop may sleep, close its lid, move between wireless access points, or wake with a different network address.

A VPN client may reconnect automatically in some environments and require manual action in others. That behavior depends on the operating system, client, device policy, and profile. Do not describe automatic reconnection as guaranteed.

Record whether the disconnect follows:

screen lock or sleep;
lid close or wake;
Wi-Fi signal loss;
switching to mobile data;
moving between office or home access points;
battery saver activation;
a client or operating-system update.

Check lifecycle status without guessing

An expired, inactive, replaced, or superseded profile can sometimes produce repeated disconnections, but a generic disconnect message does not prove a lifecycle issue. Use the authoritative account or profile-status source rather than interpreting the client label alone.

Also distinguish service renewal from profile replacement. A renewed service may continue using the same profile, while a reissued profile may require the newly delivered file. The exact workflow must follow the documented service behavior rather than a general assumption.

Run a controlled comparison

Change one approved variable at a time:

same device and profile on another authorized network;
same network after a permitted ordinary Wi-Fi reconnection, without changing security settings;
same assigned profile on another supported device, when permitted;
same device after confirming automatic date and time;
same test while the device remains awake and stationary.

Do not cycle through old or unassigned profiles. Do not disable organization controls or change firewall, router, NAT, or routing rules as a general troubleshooting step.

Create a short event timeline

The following is an illustrative timeline, not a measured test or a real customer incident:

14:02 — ordinary internet confirmed;
14:03 — client reported Connecting;
14:03 — client reported Connected;
14:11 — screen locked;
14:12 — client reported Disconnected;
14:12 — ordinary internet still available;
14:14 — second attempt remained connected while screen stayed active.

Include the client version, operating system, network type, profile revision label, and non-sensitive status wording. Do not include credentials, private configuration values, profile files, tokens, or verification codes.

Choose the next owner based on the pattern

The evidence should point toward the responsible layer:

network loss first → network owner or connectivity support;
sleep or device event → device/client documentation or device administrator;
access status non-current → service or access owner;
one specific client version → client compatibility review;
no clear trigger with a repeatable timeline → provide the timeline to support.

The goal is not to prove a cause alone. It is to collect enough structured evidence that the next person does not have to restart the investigation from zero.

What the pattern tells you

A connection that repeatedly drops after a similar interval provides more useful evidence than a single unexplained failure. Record when it disconnects, what the device and network were doing, and whether the pattern follows a specific network, device state, or profile before changing several settings at once.

Frequently asked questions

Does a brief Connected status prove the configuration is correct?

It proves only that the client reported an active state for a period. It does not explain why the session ended or guarantee that it will remain active.

Why does the VPN disconnect when the screen turns off?

The device may change sleep, background, battery, or network behavior. The exact result depends on the operating system, client, and device policy.

Should I try another profile?

Only when the authorized setup assigns another current profile. Randomly trying old or unassigned profiles makes the evidence less reliable.

What if it always disconnects after the same interval?

Record the interval precisely and report it. A repeatable interval is valuable evidence for the network, client, service, or access owner.

Can switching from Wi-Fi to mobile data end the connection?

It can. The underlying network path changes, and reconnection behavior varies by client and operating system.

Check the documentation for the exact client

OpenVPN Connect’s Android settings reference describes a Battery Saver option that pauses the connection when the screen goes blank. That is a client-specific behavior to check, not a universal diagnosis for every screen-off disconnect. Record the setting and ask the device administrator before changing managed settings.

OpenVPN Connect’s Windows release notes document changes and fixes across client versions. Record the exact installed version before comparing behavior with a release note; a similar symptom is not proof that a listed issue caused your disconnect.

How to Compare VPN Speed Tests Without Changing Every Variable

Mon, 28 Sep 2026 09:02:22 +0000

Cover: Conceptual illustration; may be AI-generated. Original creation method is unverified. Image supplied from the Lisar Website archive.

A slow result is an observation to investigate. Start by recording the test conditions, then compare repeated runs that differ in one permitted variable.

Originally written by Mohammad Hesameddin Montazerilisar, Technical Author for Lisar Connect and Manager of MONTAZERI COMPUTERS & REQUISITES TRADING CO. L.L.C. This is an edited republication of How to Read VPN Speed Tests: Latency, Distance, and Realistic Expectations. AI assisted the editing and platform presentation; no benchmark was performed for this article.

A speed test produces a number, and numbers feel like verdicts. But a test result is a measurement of one moment, on one path, through one set of conditions — and reading it as more than that is how people fool themselves in both directions, blaming a VPN for a busy network or crediting a setup for a quiet hour.

This article is about reading tests honestly: what the measurements mean, what actually moves them, and how to compare in a way that tells you something.

What a test actually measures

Most tests report several distinct things. Latency describes delay to the test endpoint; the precise measurement depends on the test method. Throughput figures describe how much data moved during a sampling window, in each direction. Each is a measurement of that moment, not a fixed property of a connection.

The first honest-reading habit follows immediately: never treat one run as a verdict. A single test tells you what one moment looked like; patterns across matched runs tell you about your setup.

The factors that move the numbers

A VPN adds a real variable — your traffic takes a path through the VPN route, and path length shows up in latency most visibly. But it joins a crowd of variables that move test results just as readily: the time of day and how busy networks are along the way, the quality of your local link at that moment (wireless conditions especially), what the device itself is doing while testing, how your internet provider routes traffic just then, the test service's own endpoint and method, and which direction of traffic the test emphasizes.

That crowd is why two tests an hour apart can differ meaningfully with nothing changed on your side — and why attributing every difference to the VPN gets the analysis wrong before it starts.

Distance and route, honestly stated

Route and distance can influence latency, alongside congestion, peering and device conditions. A geographically nearby endpoint does not by itself guarantee a better result. Identify the route and endpoint you actually tested before comparing numbers.

A specific exit, where the selected plan and setup support one, may be chosen for a routing requirement. That choice does not guarantee a latency or throughput result. Keep the intended route in the test record.

How to test so the result means something

Fair testing is mostly discipline about conditions. Test the same way each time: the same device, the same test service, comparable times of day, and a stable local link rather than a marginal wireless spot. Compare like with like — connected runs against connected runs under matched conditions, and any permitted with/without comparison done back-to-back rather than across different hours. Run more than once and look at the pattern, not the outlier. And change one thing between comparisons, because a test that varies the network, the device, and the hour simultaneously has measured everything and isolated nothing.

Do that much and your results start meaning something: not a verdict about "speed," but a readable picture of how your setup behaves under the conditions you actually use it in.

Reading results without fooling yourself

A few interpretive habits close the loop. Expect variation and treat bands, not single numbers, as the signal. Let latency and throughput answer their own questions — a distant route can add delay while data still moves well, and those are different facts. Weigh the moment: an evening test on busy networks describes evenings, not your setup. And when a result genuinely surprises you across repeated, matched runs, that's an observation worth writing down — conditions, times, device, network — because specifics are what turn "it seems slow" into something official support can actually engage with.

No test, read well or badly, changes what this series has said throughout: performance depends on many parties between you and any service, and no number from one moment promises the next. Read tests as weather reports, not contracts, and they become genuinely useful.

Read the measurement method

Cloudflare describes its test methodology, including why routing and methodology can produce different results across test services. M-Lab describes NDT as a single-stream bulk-transport measurement. The services are references for understanding a result, not interchangeable benchmarks. Review the chosen test service’s data handling before running a test.

Keep a useful comparison record

Record the device and client version, local network, VPN state, intended profile, test service and endpoint, time, and repeated results. Keep latency separate from upload and download throughput. If disconnecting the VPN is not permitted by device or network policy, keep it connected and ask the responsible administrator for an approved comparison.

No credential, profile-file contents, or private endpoint is needed in a public report. A repeated pattern under matched conditions is a useful support observation; it does not prove which component caused it.

A Safe Clock Check for VPN Validation Failures

Sun, 27 Sep 2026 08:46:22 +0000

When a VPN profile that worked previously fails during validation, the device clock is one low-risk thing to check. The useful question is whether the system represents the correct instant, not whether two devices show the same local hour.

By Mohammad Hesameddin Montazerilisar, technical author for Lisar Connect. Adapted from the original Lisar guide, published July 10, 2026 and updated September 22, 2026. AI assistance was used for editing and presentation; the technical guidance follows the original article.

Why certificate checks depend on time

Many secure connections evaluate validity periods. In certificate-based checks, the current time is compared with the certificate's validity period. If a device believes it is in the wrong day, month, or year, a certificate can appear expired or not yet valid.

RFC 5280, section 4.1.2.5 describes that validity interval. Checking the clock does not require opening a sensitive profile or inspecting private certificate material.

Correcting a wrong clock does not renew a genuinely expired certificate. If the error remains after the clock is correct, report it to the responsible service or administrator. Do not turn the clock back or disable certificate validation to make the connection work.

Separate the clock, the time zone, and synchronization

These are related settings with different jobs:

System clock: the device's estimate of the current instant.
Time zone: the rules used to display that instant as a local date and time.
Synchronization: the supported process that keeps the clock aligned with an appropriate time source.

Microsoft documents that Windows maintains system time in UTC, while local time is derived using the configured time zone.

Two devices can therefore show different local hours and still represent the same instant. A different display zone alone is not evidence of a certificate-time problem. Manually changing the hour to compensate for the wrong zone can move the actual clock away from the correct time.

Likewise, an enabled automatic-time setting does not establish that the last synchronization succeeded, particularly after a long offline period or a restored snapshot.

Use a controlled check

Check the complete date, including the year.
Check the local time and configured time zone separately.
Inspect the supported automatic-time and synchronization settings.
Confirm that ordinary internet access is available.
Follow the operating system's or organization's approved process if the clock needs correction.
Reopen the compatible VPN client and test the same assigned profile.

On a managed device, some of these controls may be administered centrally. Contact the responsible administrator when they are restricted or when the clock repeatedly changes. A VPN troubleshooting task is not permission to override device policy.

Keep the comparison small. Replacing the profile, changing networks, adjusting the clock, and updating the client in one step makes the result harder to interpret.

Treat symptoms as clues

A validation failure after a device has been restored, a previously working profile failing on one device, or date-related warnings from other secure services can justify a clock check. None proves that time is the cause.

Record the exact client message and the stage at which it appears. A broad connection error can represent several different causes.

If another authorized device works with the same assigned profile, compare its clock, operating-system version, client version, network, and failure stage. Do not borrow another person's profile to create a comparison.

Continue when the clock is correct

After the clock check, return to the ordinary diagnostic order: internet access, current profile assignment, compatible client, required permissions, and the exact connection stage.

Repeatedly importing the same file is unlikely to clarify a clock issue. It can leave several similar entries in the client and make the intended profile harder to identify.

A useful support note records the device and client versions, whether date and synchronization were checked, the network type, the exact status, and what happened in a controlled retest. Keep profile files, credentials, and private account details out of a public report.

The clock check is a small diagnostic step with a specific purpose. It helps separate time-based validation from display preferences while keeping the existing security checks in place.

Cover: Conceptual illustration; may be AI-generated. Original creation method is unverified. Image supplied from the Lisar Website archive.

A Local Printer Disappears on VPN: A Non-Destructive Diagnostic Checklist

Tue, 22 Sep 2026 08:45:39 +0000

A printer missing from the discovery list can look like a VPN failure even while websites continue to load. The first task is to identify which destination and which operation are failing. This checklist keeps the comparison controlled and leaves network changes with the responsible administrator.

Separate the destination from the connection state

A website is an internet destination. A printer, NAS, or casting device in your building is usually a local-network destination. Reaching one does not establish that you can reach the other. A working internet connection can therefore coexist with a missing nearby device.

Keep the symptom specific. “The printer is absent from the device list” describes a discovery problem. “The printer is listed, but the job does not complete” describes a different observation. Neither observation alone proves the VPN service is down. Start with what the device actually shows.

Check the local device before changing the VPN setup

Confirm that the printer or storage device is powered on, awake, and connected to the network you expect. Check whether the computer is on that same intended local network. A nearby object is not necessarily reachable from the network your computer has joined.

Then open a known website while the VPN is connected. Record the result separately from the local-device result. If browsing works, focus the next checks on local access and discovery. If browsing also fails, keep that broader symptom visible rather than treating every failure as a printer problem.

Compare conditions one at a time

Where your device and network policies permit it, note whether the same nearby device is reachable with the VPN disconnected. Do not interrupt a connection that your organization requires to remain active. Ask the responsible administrator for an approved comparison instead.

A change associated with the connection is a useful clue, not a complete diagnosis. Avoid changing the client, profile, network, and printer configuration at once. That would remove the stable baseline needed to understand the difference.

If another authorized device is available on the same local network, compare its result too. Record the operating system, VPN client, and connection state of each device. One laptop working while another fails does not prove the profile is faulty; their local conditions may differ.

Account for where the VPN runs

A VPN client on one laptop and a VPN connection on a router are different arrangements. They relate to the local network differently, and neither arrangement guarantees access to every nearby device.

Client behavior, operating-system settings, and network policy also matter. Do not assume that a particular printer, NAS, router, or client combination will behave the same everywhere. The documented setup and the network owner's requirements determine which behavior is intended.

Keep configuration changes with their owner

This first check should produce a clear observation, not an improvised routing change. On a workplace, venue, or managed network, ask its administrator whether local-device access is permitted and which setup supports it.

Do not disable firewalls, change router settings, or add broad access rules just to make discovery work. Those decisions belong to the person responsible for the network. Lisar profile management does not replace network administration or grant permission to reach local resources.

Use platform guidance for the next supported step

Microsoft's network printer sharing guidance covers the requirements for a Windows shared printer. Apple's printing troubleshooting guidance includes checking the printer's power and network connection and asking its manager for help when needed.

Apply the guidance that matches the actual device and approved setup. These references do not establish universal printer compatibility with Lisar or promise that a VPN setting will solve the problem.

What the checks establish

If the internet works but the nearby device does not, keep the local-access question separate. Confirm power and network membership, compare permitted connection states, and record device differences. Then use the network owner's supported path. This narrows the question without presenting an untested configuration change as a fix.

Cover: Conceptual illustration; may be AI-generated. Original creation method is unverified. Image supplied from the Lisar Website archive.

How Kubernetes Networking Works | Pods, Services & DNS Explained for Beginners

Mon, 21 Sep 2026 12:24:10 +0000

A new video is out!

I’m explaining Kubernetes networking in my little way, especially how Pods, Services, and DNS work together.

If you’re learning Kubernetes and networking has been confusing, this one is for you.

How Kubernetes Networking Works | Pods, Services & DNS Explained for Beginners

Watch the full video here

Kubernetes #DevOps #CloudNative #TechCommunity

Before You Import a VPN Profile, Check Who Manages the Device

Mon, 21 Sep 2026 08:38:30 +0000

When a VPN rollout reaches a company laptop, the first dependency is often a policy decision. The person using the device may not be allowed to install a client, add a profile, import a certificate, or change network settings. A useful preflight makes those boundaries explicit before anyone starts changing the machine.

Establish the policy owner

Start by separating personal, company-managed, and client-managed devices. Ask who owns the policy for each group. The person who uses a laptop every day is not necessarily the person authorized to approve its apps or network configuration.

This matters particularly for contractors using a client's hardware. A setup path accepted on your own company's devices does not establish permission on the client's device. Route the question through the team that manages that device.

Check the four surfaces setup may touch

Ask the policy owner which actions are permitted:

Installing the intended VPN client.
Adding or importing a VPN profile.
Importing certificates, when the approved setup requires them.
Changing relevant network settings.

Treat an unclear answer as an unresolved dependency. Do not use repeated installation attempts or unrelated settings changes to discover a policy by trial and error. A blocked control is a reason to ask its owner for the supported path.

Device management may also provide the configuration centrally. Microsoft documents assigning VPN settings to users and devices through Intune. Apple's deployment documentation describes managed VPN payloads and their platform and enrollment constraints. These are examples of management mechanisms; they do not establish which policy your organization uses or certify any particular service integration.

Record the permitted path before rollout

A compact planning record can answer six questions:

Which device group is in scope?
Who confirmed the applicable policy?
Which client and configuration method are permitted for that group?
Where does each person obtain the profile assigned to them?
Who handles setup questions or a blocked step?
What is the disposition when no setup path is permitted?

The last answer can legitimately be “no setup on this device.” Keep that decision visible so it is not mistaken for unfinished installation work. Record ownership and instructions without putting profile contents, credentials, tokens, or private keys into the shared document.

A profile file operates within the policy

Where device policy permits an appropriate OpenVPN-compatible client, an assigned .ovpn file provides that client's connection configuration. The file does not grant installation rights or change management restrictions.

For Lisar, profile-specific information comes from the user's own Panel profile. Select a setup method supported by the actual device and allowed by its policy. Keep downloaded profile files and access material out of shared planning documents and public support threads.

A successful file download is therefore one step in an allowed setup process. It is not evidence that the device owner has approved that process.

Travel and router placement do not remove the boundary

A managed laptop remains managed at home, at a hotel, or in a coworking space. Check its approved setup before departure, when the policy owner and support team are available. A change of location does not create permission for an improvised configuration.

Router-based VPN setup also changes where the connection is handled, not who controls the laptop. It depends on the router's actual compatibility and the approved network plan. It does not remove device restrictions or substitute for permission to use a service.

Verify the agreed scope

Once the policy owner has confirmed an allowed path, follow the corresponding instructions and verify the intended connection and authorized resource separately. If a step is unavailable, preserve the observed stage and ask the responsible team to resolve it.

VPN setup does not replace endpoint security, identity management, SSO, device management, firewall policy, or the organization's other controls. A connection by itself does not guarantee access to a company system. The practical outcome of preflight is a clear owner and a permitted setup path for each device group.

Platform references

These references describe platform management capabilities. Your organization's IT team determines the configuration and policy that apply to its devices.

Conceptual illustration; may be AI-generated. Original creation method is unverified. Image supplied from the Lisar Website archive.

Cover image description: A blue illustration shows a laptop with a VPN warning and a broken connection path. Beside it, linked icons represent notes, a screenshot, a clock, and a report; a checklist notebook sits in front. This is conceptual artwork, not a live interface or test result.

Before You Ask for VPN Help: Record the Stage, Status, and Timeline

Sun, 20 Sep 2026 09:03:09 +0000

Before trying another fix, record the last successful setup stage, the exact status, and the timing. A small, controlled problem report is more useful than a list of unrelated changes.

By Mohammad Hesameddin Montazerilisar, who writes technical guidance for Lisar Connect. Edited with AI assistance from the author's original article, published July 10, 2026 and updated July 11, 2026. The substantive guidance comes from that human-authored source.

Cover illustration: A blue illustration shows a laptop with a VPN warning and a broken connection path. Beside it, linked icons represent notes, a screenshot, a clock, and a report; a checklist notebook sits in front. This is conceptual artwork, not a live interface or test result. Existing source artwork, potentially AI-generated; the original creation method is unverified.

Identify the last step that worked

“VPN not working” describes an outcome, but it does not show where the process stopped. Separate downloading the profile, importing it, approving the device permission, connecting, and using the connection.

Record the last stage you can confirm:

The profile file downloaded.
The compatible client accepted the file.
The profile was imported or saved.
The operating system allowed the VPN configuration.
The client attempted to connect.
The client showed an active connection.
Internet access and the expected services worked after connection.

“Import succeeded, but Connect returns to disconnected after ten seconds” gives the reviewer a specific transition to investigate. If you cannot tell whether import completed, say so. Uncertainty is useful when it identifies the next fact to check.

Record the device, client, and network

Include the device type, operating-system version, VPN client and version, and whether the device is personal or managed by an organization. Use the version actually shown by the device or client. Also note whether the setup worked before and whether software changed recently.

Record the network type: home or office Wi-Fi, hotel or public Wi-Fi, or mobile data. Note whether ordinary internet access worked before the VPN attempt and whether a network sign-in page appeared. If the device moved between Wi-Fi and mobile data during the test, include that fact.

Do not change an organization's router or firewall settings to create a comparison. When appropriate, a second network you are allowed to use is enough. A successful test on one device also does not establish that another device has the same client capabilities or operating-system behavior.

Preserve the exact wording and a short timeline

Write down the client's actual status or error. Keep the observation separate from your interpretation.

“The client shows Connecting for 15 seconds, then returns to Disconnected” records behavior. “The server rejected me” assigns a cause that the observation alone may not establish.

Note when the wording appeared: during import, when Connect was pressed, or after an active connection had been shown. Add the approximate date and local time, the last successful connection, the first failed attempt, and relevant changes between them.

A few lines are enough. The original guide gives this illustrative sequence: a successful connection on home Wi-Fi, an operating-system update that evening, a connection failure the next morning despite a successful import, and the same result on mobile data that afternoon. The sequence is an example, not a measured incident or a claim that the update caused the failure.

Keep the evidence small and private

A screenshot can preserve a status message or permission prompt. Review it before sharing and remove unrelated account names, email addresses, billing information, notifications, device identifiers, QR codes, access links, and credentials.

Capture the relevant status area without opening the profile's contents. Pair the image with the stage and time; a screenshot alone may omit what happened immediately beforehand.

Do not routinely attach an assigned profile file, password, verification code, token, cookie, private key, or certificate material. Start with device, version, stage, network type, wording, and timing. If a formal support process requires more, confirm the recipient and channel and follow that process.

Use a repeatable report

Copy the fields below into your notes and fill only what you can establish:

Device and operating-system version:
VPN client and version:
Personal or managed device:
Assigned profile current or uncertain:
Network used:
Ordinary internet access before VPN:
Last successful setup stage:
Exact status or error:
Approximate date and local time:
Last known successful connection:
Recent changes:
Result on another allowed network or device:
Screenshot reviewed for private information:

This record identifies the setup and the failure without exposing the profile itself.

Change one variable at a time

Keep the device, client, and profile fixed when comparing two allowed networks. For an authorized comparison between devices, keep the network and intended profile assignment clear.

Changing clients, importing several copies, switching networks, and altering device settings in one pass makes the final result harder to interpret. Stop once the evidence is sufficient. More tests are not automatically better, especially on managed devices.

Questions to settle before sending

What matters most? The last successful stage and the stage that failed. “Imported but did not connect” gives support a clearer starting point than “not working.”

Should the profile file be attached? Not as a routine first step. Begin with the limited record above; use an explicitly authorized process if more is required.

Why record the time? It helps correlate the issue with software, profile, network, or service changes without sharing credentials.

Are screenshots enough? They are useful when reviewed for private information and accompanied by the stage and timeline.

Further reference

OpenVPN Connect: Import a Profile documents the import stage.
OpenVPN Connect: Troubleshooting Hub separates connection-profile and authentication help.
OpenVPN Connect: Troubleshooting FAQs provides client-specific guidance; use the section matching the observed issue.

DHCP Snooping (Networking)

Tue, 15 Sep 2026 02:43:10 +0000

What is DHCP Snooping?
DHCP snooping is a Layer 2 security feature on network switches that blocks unauthorized devices from acting as fake DHCP servers.
I practiced it via Cisco Packet tracer.

ICMP vs TCP vs UDP: the difference, explained for developers

Sun, 13 Sep 2026 10:00:58 +0000

TL;DR. ICMP, TCP and UDP all travel inside IP packets, but they ask different questions. ICMP echo (ping) asks "does this address answer at all?" and needs no port. TCP asks "is a program listening on this port?" and gets a clear yes, a clear no, or silence. UDP asks nothing by itself: you only learn something if the program on the other side chooses to reply. A closed port answers differently on each one, and that difference is most of what a network check can and cannot tell you. The original post has the same text with a collapsible FAQ and the RFC list at the end.

One address, three ways to knock

Every packet on the internet is an IP packet. IP knows how to move a packet from one address to another and nothing else. One byte in the IP header says what is inside, and IANA keeps the list: ICMP is protocol 1, TCP is protocol 6, UDP is protocol 17. The three are siblings: same addresses, same routers, and a different promise about what happens once the packet arrives.

Three ways to knock on one address. The last row of each lane is what silence means there.

	ICMP	TCP	UDP
Specification	RFC 792 (1981), RFC 4443 for IPv6	RFC 9293 (2022)	RFC 768 (1980)
IP protocol number	1 (58 for ICMPv6)	6	17
Ports	none	source and destination	source and destination
Handshake	none	three packets before any data	none
Delivery guarantee	none	ordered, complete, retransmitted	none
Header	8 bytes for an echo	20 bytes minimum	8 bytes
Typical users	ping, traceroute, error reports	HTTP/1.1 and HTTP/2, TLS, SSH, SQL, SMTP	DNS, NTP, QUIC and HTTP/3, video, games

ICMP: the network talking about itself

ICMP is not a transport. RFC 792 says it plainly: ICMP "is actually an integral part of IP, and must be implemented by every IP module." It exists so that routers and hosts can report on delivery: this destination is unreachable, that packet ran out of hops. ICMP messages have a type and a code but no ports, because nothing sits on top of ICMP waiting for them. The IP stack consumes them itself.

The one ICMP message everybody has typed is the echo. ping sends an echo request (type 8, or 128 in ICMPv6) and the far host's kernel sends back an echo reply (type 0, or 129). No program had to be running. RFC 1122, the host requirements standard, makes it a rule: "Every host MUST implement an ICMP Echo server function that receives Echo Requests and sends corresponding Echo Replies."

$ ping -c 1 uptimepage.dev
PING uptimepage.dev (204.168.246.94): 56 data bytes
64 bytes from 204.168.246.94: icmp_seq=0 ttl=50 time=96.069 ms

A reply proves two things: the address belongs to a machine that is switched on, and packets can travel there and back. It also gives you the round-trip time for free.

That is all a ping proves. It says nothing about whether a web server, a database or anything else is running, and a host can answer every ping while every service on it is dead.

Two things about ICMP surprise people. The first is that no reply does not mean down. Firewalls drop ICMP all the time. On AWS a fresh security group blocks it, and the documentation says so: "To ping your instance, you must add one of the following inbound ICMP rules." Before you rely on ping for a host, confirm the host answers a ping at all.

The second is that sending ICMP needs privilege. A raw socket needs CAP_NET_RAW. Linux has an unprivileged alternative, the ICMP datagram socket, but the kernel documentation says the default ping_group_range is "1 0", "meaning, that nobody (not even root) may create ping sockets." Docker opens that range in every container that gets its own network namespace, which is why ping works there without anyone thinking about it; a container on --network host inherits the host's setting instead. I learned the limits of that the slow way: the same probe binary that pinged fine in Docker could not open an ICMP socket at all on a Firecracker microVM, until I gave it CAP_NET_RAW.

TCP: a promise before the first byte

TCP is a connection. Before either side sends a byte of data, the two ends run the three-way handshake: SYN, SYN-ACK, ACK. RFC 9293, which replaced the 1981 specification in 2022, calls it "the procedure used to establish a connection." It costs one round trip, and that round trip pays for every promise TCP makes afterwards: bytes arrive in order, lost segments are sent again, the receiver is not flooded (flow control), and the network is not flooded (congestion control). To the program it looks like a stream. You write bytes on one side and read the same bytes, in the same order, on the other.

This is what HTTP/1.1, HTTP/2, TLS, SSH, PostgreSQL, MySQL, SMTP and most of what you deploy run on.

The handshake is also a good probe, because a SYN gets one of three answers:

SYN-ACK. A program is listening. The connect succeeds.
RST. Nothing is listening. RFC 9293 says that if the connection does not exist, "a reset is sent in response to any incoming segment except another reset." Your connect fails at once with "connection refused".
Nothing. A firewall dropped the SYN, or the host is gone. The kernel keeps retrying. On Linux the default tcp_syn_retries is 6, and the kernel documentation puts the final timeout for an active connection attempt at 131 seconds.

Here are all three from my laptop. The last one has a three second limit; without it macOS waits 75 seconds.

$ nc -zv uptimepage.dev 443
Connection to uptimepage.dev port 443 [tcp/https] succeeded!

$ nc -zv 127.0.0.1 9
nc: connectx to 127.0.0.1 port 9 (tcp) failed: Connection refused

$ nc -zv -G 3 uptimepage.dev 8443
nc: connectx to uptimepage.dev port 8443 (tcp) failed: Operation timed out

Nmap's documentation gives these states the names everyone uses: open, closed and filtered.

What a successful handshake proves: a process accepted a connection on that port. Not that it is healthy. A database that accepts connections and then rejects every query still passes. That is why a TCP check belongs on things that have no HTTP surface (SSH, SMTP, a database port) and an HTTP check belongs on things that do.

UDP: a message, nothing more

UDP is the smallest transport there is. RFC 768 fits on three pages. It adds a source port, a destination port, a length and a checksum to an IP packet, 8 bytes in total, and stops. The RFC says: "The protocol is transaction oriented, and delivery and duplicate protection are not guaranteed." There is no handshake, no acknowledgement, no ordering and no retransmission, and no congestion control either. RFC 8085 opens by saying UDP "has no inherent congestion control mechanisms" and then spends more than fifty pages telling application designers how to add their own.

Why anyone uses it: latency and control. A DNS lookup is one packet out and one packet back, no handshake. RFC 1035 capped a DNS answer over UDP at 512 bytes. EDNS(0) (RFC 6891) later let a client advertise a bigger buffer, so most answers fit in one datagram today; one that still does not fit is cut short with the TC bit set, and the client asks again over TCP (RFC 7766). NTP, most game traffic and real-time video use UDP because a late packet is worth less than the next one, so waiting for a retransmission is the wrong trade. And QUIC, the transport under HTTP/3, is built entirely on UDP. RFC 9000 states that "QUIC packets are carried in UDP datagrams" and gives the reason as "to better facilitate deployment in existing systems and networks". In practice that means QUIC does its own handshake, loss recovery and congestion control in the application, and can change them without waiting for every operating system to update its TCP stack.

$ dig @1.1.1.1 uptimepage.dev A +noall +answer +stats
; <<>> DiG 9.10.6 <<>> @1.1.1.1 uptimepage.dev A +noall +answer +stats
; (1 server found)
;; global options: +cmd
uptimepage.dev.3600INA204.168.246.94
;; Query time: 125 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Wed Sep 02 11:40:44 EEST 2026
;; MSG SIZE  rcvd: 59

One datagram out, one datagram back carrying a 59-byte answer (67 bytes with the UDP header), and no handshake before it. Over TCP the same lookup costs two round trips, one for the handshake and one for the query, which is why DNS defaults to UDP.

Now the probing problem. Send a UDP datagram to a port and what comes back?

If nothing listens there, the host's IP stack should answer with an ICMP error. RFC 1122 again: "If a datagram arrives addressed to a UDP port for which there is no pending LISTEN call, UDP SHOULD send an ICMP Port Unreachable message." So "closed" is detectable, and it is ICMP that detects it.

If something listens, you get whatever that program chooses to send. A DNS server sends an answer. A syslog receiver sends nothing, ever. So silence means open, or filtered, or dead, and Nmap has a state for this, open|filtered. Its documentation explains: "This occurs for scan types in which open ports give no response."

The consequence is that a generic "UDP port check" does not exist. To check a UDP service you have to speak its protocol: send a real DNS query and read the answer, send a real NTP request and check the timestamp. This is why monitoring tools have a DNS check and a TCP check but rarely a UDP check.

The same closed door, three answers

Situation	ICMP echo	TCP SYN	UDP datagram
Service up	echo reply	SYN-ACK	the program's reply, or nothing
Port closed, host up	echo reply (ICMP has no ports)	RST, "connection refused"	ICMP port unreachable
Firewall drops the packet	silence	silence, retried for about two minutes	silence
Host gone	silence, or an unreachable error from the last router	silence, or that same ICMP error surfacing as "no route to host"	silence, or that same ICMP error

Read the table by columns. TCP is the only one where "closed" and "filtered" look different on their own, UDP borrows ICMP to say "closed", and ICMP cannot see ports at all. Silence is the ambiguous answer on all three, which is why no check should conclude "down" from one silent probe sent from one place. Two or three consecutive misses, seen from more than one network, is the honest bar. I wrote about that in how to stop false uptime alerts.

What this means for a monitor

I build Uptimepage, and its check types map onto these questions, so this is how the theory turns into a config.

Ping sends one ICMP echo with a 32-byte payload, the size Windows ping uses (Unix ping sends 56, as the transcript above shows), so middleboxes see ordinary diagnostic traffic. It tries the first IPv4 and the first IPv6 address of the host and splits the timeout between them. Silence for the whole budget is down, because an echo has no way to refuse. Use it for routers, gateways and hosts that expose no service.
TCP runs the handshake and closes the connection. Accepted is up, refused is down, and a timeout is recorded as an error with the time it took. An error counts as a failed check for alerting exactly like down, so a firewalled port still opens an incident once the confirmation threshold is met. Use it for databases, brokers, SSH and mail, where "a process accepted the connection" is the most you can assert from outside.
DNS sends a real query and checks the answer's content, so it is the UDP check for the one UDP service almost everyone depends on. It can point at a specific resolver, which matters when you want that server's view and not your cache's.
HTTP is a TCP handshake, then TLS, then a request, and it records the time spent in each phase: DNS, connect, TLS and time to first byte. The connect phase is the handshake from this article, measured inside a bigger check.

Pick the check that asks the question you care about, and remember what each one cannot see. There is a fuller version of that decision in the monitor types documentation, and a story-shaped version in the mystery of the "down" website.

Common questions

Is ICMP a transport protocol like TCP and UDP?

No. ICMP is a control protocol that belongs to IP itself, and RFC 792 says every IP module must implement it. It has no ports and carries no application data. It reports on delivery: a destination is unreachable, a packet ran out of hops, and the echo pair that ping uses.

Why does ping work while my website is down?

Because ping only proves that the host's IP stack answers and that packets can travel there and back. The kernel sends the echo reply, so no web server, database or other program has to be running. A host can answer every ping while every service on it is dead.

Why does a closed TCP port fail at once but a firewalled one hangs?

A closed port sends back a TCP reset, so the connect fails immediately with connection refused. A firewall that drops the SYN sends nothing, and the kernel keeps retrying. On Linux the default is six retries, and the kernel documentation puts the final timeout at 131 seconds.

Can I check a UDP port the way I check a TCP port?

No, because an open UDP port sends nothing back unless the program behind it chooses to answer. A closed port is detectable, since the host should reply with an ICMP port unreachable message, but open and filtered both look like silence. To check a UDP service you have to speak its protocol, for example send a real DNS query.

If UDP is unreliable, why does HTTP/3 use it?

UDP itself gives no delivery guarantee, and QUIC adds its own on top. QUIC runs inside UDP datagrams and does its own handshake, retransmission and congestion control in the application, which lets it evolve without waiting for every operating system to update its TCP stack.

Sources

IETF, RFC 792: Internet Control Message Protocol, September 1981.
IETF, RFC 4443: ICMPv6 for the Internet Protocol Version 6, March 2006.
IETF, RFC 768: User Datagram Protocol, August 1980.
IETF, RFC 9293: Transmission Control Protocol, August 2022.
IETF, RFC 1122: Requirements for Internet Hosts, Communication Layers, October 1989. Sections 3.2.2.6 and 4.1.3.1.
IETF, RFC 8085: UDP Usage Guidelines, March 2017.
IETF, RFC 1035: Domain Names, Implementation and Specification, November 1987. Section 4.2.1.
IETF, RFC 6891: Extension Mechanisms for DNS (EDNS(0)), April 2013.
IETF, RFC 7766: DNS Transport over TCP, Implementation Requirements, March 2016.
IETF, RFC 9000: QUIC, a UDP-Based Multiplexed and Secure Transport, May 2021.
IANA, Assigned Internet Protocol Numbers.
Linux kernel, IP sysctl documentation, tcp_syn_retries and ping_group_range.
Nmap, Port scanning basics, the six port states.
Amazon Web Services, Security group rules for different use cases, rules for ping/ICMP.

I build Uptimepage because I wanted these checks for my own services: ping, TCP, DNS and HTTP with per-phase timing, plus TLS and domain expiry, heartbeats for background jobs, and browser flows, from several regions. It is AGPL-3.0 open source, so you can run it on your own server if you prefer.

Now the question for the comments: do you still run ping checks on anything, and what for? I keep them for routers, gateways and hosts that expose no service, and almost nothing else. If a ping check has earned its keep for you somewhere I have not listed, I would like to hear where.

VPN Client, Profile, and Service: Three Roles to Check During Setup

Sun, 13 Sep 2026 09:55:01 +0000

A working VPN setup involves software, connection instructions, and a service account. This guide separates those responsibilities so that an import problem is not confused with a connection-state or profile-management question.

By Mohammad Hesameddin Montazerilisar. This article is adapted from the author’s original Lisar Connect article, first published July 8, 2026 and updated September 11, 2026. The author writes technical guidance for Lisar Connect. AI assisted the editing and presentation of this human-authored source.

Illustration of a client connection-status dashboard, not a screenshot of the current Lisar UI or a measured test.

The client runs the connection

The VPN client is the program on your device that establishes and maintains the connection: the software with the connect control, status indicator, and prompts. In an OpenVPN Connect setup, it reads the imported OpenVPN profile and runs the connection on the device.

Client, profile, and service describe different roles. The client runs the connection, the profile supplies its connection settings, and the service manages the account, profiles, and plan. Follow the current setup guide for your device and profile when choosing the software and settings to use.

This distinction matters before troubleshooting begins. A client can be installed without the intended profile being present. A profile can be imported without a connection being established. Check the stage that has actually completed instead of treating the app's presence as proof that every part is ready.

The profile supplies the connection instructions

The client needs to be told what connection to run, and that is the profile's job. In the documented OpenVPN Connect flow, the profile arrives as a .ovpn file carrying the setup information for that particular connection. Obtain it from the approved source for your own assignment and follow the guide for the intended device.

The file-import sequence brings the parts together: obtain the current .ovpn file, open OpenVPN Connect, choose Upload File, import and save the profile, and connect. The exact screens depend on the client version and device; the current supported guide takes precedence over remembered button wording.

Because the file carries profile-specific setup information, treat it as sensitive material. Do not paste its contents into a support ticket or public discussion. Do not pass it through casual chats or shared folders. When a new device needs setup, use the approved download and assignment process rather than borrowing another person's file.

The service manages accounts, profiles, and plans

Behind the client and file sits the service layer. It manages the account, profiles, and plan. Its current management interface is where profile-specific questions belong: which assignment is current, what the plan includes, and what status the service records for a profile.

Connection-state questions start at the client and device in front of you. Questions about the client software belong with its maker's documentation. Profile and plan questions belong with the service's management interface and official support. A status shown in one layer does not automatically answer a question about another.

Ask each part the right question

The service layer manages the assignment, the profile carries the instructions, and the client runs them. In the documented OpenVPN Connect flow, these roles meet in that order: management interface to file to client. Other supported setup paths use the settings and software specified in their own guides.

Consider three common questions:

“The button says disconnected.” Start with the current client and device state. Record the wording and the stage where setup stopped.
“Is my profile still active, and what does my plan include?” Check the current service-side information, rather than inferring it from an old downloaded file.
“Which file should this new tablet use?” Confirm the intended assignment and obtain its current profile through the supported process for that device.

This keeps a support request precise. Instead of “my VPN is missing,” describe which client is installed, whether the intended profile has been imported, what the client currently reports, and which service-side status you checked. Keep the profile contents and other secrets out of that record.

Keep expectations within each layer

The client reports connection state; it does not decide what an unrelated website or application does with the traffic. The profile supplies connection settings; it does not grant permission to use unrelated accounts or services. The service manages its own plans and profiles; it does not override the rules of networks or devices you do not control.

On a managed device, follow the organization's setup process. Use the supported client and assigned profile, then verify the connection separately. The model is useful because it gives each question an appropriate starting point without promising that one status indicator proves everything.

Frequently asked questions

Is OpenVPN Connect itself the VPN service?

No. OpenVPN's documentation distinguishes its client application from the compatible server or service that supplies the connection profile.

Does importing a profile mean I am connected?

Importing makes the profile available to the client. Check the client's current connection state after the connection step; do not infer it from an import confirmation.

Where should a profile or plan question go?

Use the service's current management interface and official support. For client-software questions, use the client's own documentation. Do not share profile contents to explain which layer you are checking.

References

OpenVPN Connect: Import a Profile — the file-import flow and the distinction between client and service.
OpenVPN Connect: How to Get Your Connection Profile — obtaining the profile from the responsible provider, administrator, or supported server setup.

VPN Troubleshooting: One Layer at a Time, A Diagnostic Checklist

Sat, 12 Sep 2026 15:24:57 +0000

By Mohammad Hesameddin Montazerilisar

Originally published on Lisar Connect.

Author disclosure: I write technical guidance for Lisar Connect. I wrote the original article; AI was used only for editorial assistance.

VPN troubleshooting goes wrong in a predictable way: people change three things at once, and whatever happens next, they have learned little about the cause. A more useful approach is to check one layer at a time, in an order that rules things out, and write down what each check shows. This checklist provides that order.

Before starting, respect the policies of the network and device you are using. If your organization manages the device, involve its IT team. Do not disable device security tools as a troubleshooting step. The goal is to identify where a problem occurs while staying within the supported setup.

1. Check the device basics

Start with the simple checks: restart the VPN client. If that changes nothing, restart the device. Confirm that the operating system and VPN client are up to date through their supported update process.

Note whether anything changed around the time the problem started: an operating-system update, a new application, different settings, or a change of location. Record the timing before making further changes. It gives you something concrete to compare with the client's behavior.

2. Test the internet without the VPN

Disconnect the VPN and test ordinary browsing. If the connection also fails without the VPN, resolve the underlying internet connection first. There is little value in diagnosing later layers while this baseline does not work.

If browsing works without the VPN and fails with it, you have narrowed the problem. Write down that difference before continuing.

3. Read the client's actual state

Open the client and inspect what it reports. Is it connected, still trying to connect, or disconnected? Is the correct profile selected—the current one, rather than an older entry left over from a previous setup?

Disconnect and reconnect once, deliberately, and watch the result. Record the status or error message instead of relying on a general description such as “the VPN is broken.”

If several profiles have accumulated in the client, note that too. Selecting a stale entry can make the behavior difficult to interpret. Confirm which profile the current setup instructions require before changing or removing entries.

4. Confirm that the profile is current

A setup that worked for months and then stopped deserves a profile-lifecycle check. Verify whether the profile is still active and whether it has been replaced or its status has changed.

For a Lisar profile, check the Lisar Panel and the current setup instructions. If the profile has been replaced, follow the supported setup flow: download the current .ovpn file, open OpenVPN Connect, choose Upload File, import and save the profile, and connect. Once the replacement is working, remove the superseded file and stale client entry as directed by the setup instructions.

The current Panel and setup guidance are the reference for this check. An old downloaded file or saved note may no longer describe the active profile.

5. Record DNS-shaped symptoms precisely

Sometimes the client reports a connection while browsing still fails: pages do not load by name, or applications cannot find their services. Treat this as a pattern to investigate, rather than a diagnosis to assume.

Reconnect once. Try another site or application to check whether the problem affects more than one destination. Record exactly what fails and what still works.

Avoid changing DNS or other configuration based on unrelated advice threads while you are collecting evidence. A precise description—such as “the client reports connected, but these names fail to load”—is useful to official support. Changing several settings at once can erase the distinction you were trying to capture.

6. Compare with another permitted network

Try the same device and setup on a different network you are permitted to use: for example, home Wi-Fi and mobile data. Keep the device and profile the same so that the network is the variable being compared.

If the problem follows the device, revisit the earlier device, client, and profile checks. If it stays with one network, that network's behavior or policies are part of the investigation.

On a network you do not control, respect those policies. Use a permitted network that works, record the difference, and involve the appropriate administrator when needed.

7. Send support a useful record

Even if the checklist does not resolve the problem, it can produce a much clearer support request. Include:

The device and operating-system version.
The VPN client and its version.
When the problem started and what changed around that time.
The checks you performed and what each showed.
The client's status or error message.
Which networks behaved differently.

Review screenshots for profile-specific or sensitive details before sending them. Use official support channels rather than posting profile information publicly.

A concise report of the checks and their results gives support a starting point. It records both where the problem appears and which layers you have already tested.

Frequently asked questions

What order should I follow?

Check the device basics, internet access without the VPN, the client's state, profile freshness, DNS-shaped symptoms, and behavior on a different permitted network. Record each result before moving on.

My VPN worked for months and suddenly stopped. Where should I look?

Include the profile's current status in your checks. For Lisar, verify it in the Panel. If the profile has been replaced, use the current file and supported import process instead of repeatedly reconnecting with the old entry.

It connects, but pages and applications cannot find anything. What next?

Reconnect once, test another destination, and capture the exact symptoms. A connected client does not explain every application failure; give official support the observed pattern before changing configuration.

What does failure on only one network tell me?

It identifies a useful difference. Record which network works and which does not, keeping the device and profile unchanged. The network's behavior or policies may need the administrator's attention.

Should I switch off security tools to test the VPN?

No. Keep device security protections in place. On a managed device, involve your organization's IT team in the troubleshooting.

References

How the Internet Finds Its Way: A Guide to DNS Resolution

Mon, 07 Sep 2026 09:55:22 +0000

Have you ever wondered how typing a few letters into your browser magically brings up your favorite website in milliseconds? This seamless connection is powered by a vital background process called DNS resolution.

What is DNS Resolution?

DNS (Domain Name System) resolution is the translation process that converts human-readable web addresses, like dev.to or google.com, into machine-readable numerical coordinates known as IP (Internet Protocol) addresses, such as 192.0.2.1. Computers and servers do not understand words; they communicate entirely through numbers. DNS resolution acts as the global, automated directory of the internet, mapping names to numbers so that your web browser can establish a connection to the correct server.

The Contact List Analogy

To understand how this works, think about making a phone call to your friend, Alex. You probably do not have Alex’s ten-digit phone number memorized. Instead, you open your phone’s contact list, search for the name "Alex," and tap the call button. Your phone looks up the name "Alex" in its local database, retrieves the associated phone number, and dials it.

In this analogy, the name "Alex" is the domain name (like mysite.com). Your phone's contact list is the DNS directory, and the ten-digit phone number is the numerical IP address. Without this automated lookup, you would have to carry around a physical notebook of numbers for every person you ever wanted to call, just as you would have to memorize long strings of numbers for every website you want to visit.

The Journey of a Lookup

When you request an IP address, your computer does not just search one massive list. The request goes on a rapid relay race:

The Recursive Resolver: Usually managed by your Internet Service Provider (ISP), this acts as your personal assistant, hunting down the address on your behalf.
The Root Server: The assistant asks the Root Server, which directs them to the top-level directory (like the .com or .org registry).
The TLD Server: The Top-Level Domain server pointing specifically to where that type of domain is managed.
The Authoritative Name Server: The final destination that holds the official, absolute mapping of the domain to the IP address.

Why It Matters in the Tech Industry

For software engineers and system administrators, understanding DNS resolution is critical. It is the bedrock of how web traffic is routed, secured, and optimized.

First, engineers use DNS settings to implement failovers and high availability. If a primary server in New York goes offline due to a power outage, engineers can quickly update the DNS records to point the domain to a healthy backup server in Chicago. Users will still type the same website name, completely unaware that they are now being served from a different physical location.

Second, DNS resolution directly affects website latency. Every time a user visits a site, their device must perform a DNS lookup. If this lookup takes too long, the website feels slow, even if the hosting server itself is lightning-fast. Engineers optimize this by using Content Delivery Networks (CDNs) and configuring "Time-to-Live" (TTL) settings to cache these lookups closer to the user.

DNS Resolution in Code

Here is how you can perform a DNS resolution programmatically in JavaScript using Node.js. This script takes a domain name and returns its corresponding IPv4 address.

const dns = require('dns');

const domain = 'dev.to';

dns.resolve4(domain, (err, addresses) => {
  if (err) {
    console.error('Error during DNS resolution:', err.message);
    return;
  }

  console.log(`The IP addresses for ${domain} are:`);
  addresses.forEach((ip) => {
    console.log(`- ${ip}`);
  });
});

The Takeaway

DNS resolution is the digital translator that bridges human language with computer networking. By mastering how domain names are mapped to IP addresses, engineers can design systems that load faster, route users intelligently around the globe, and survive server failures with zero interruption to the end user.

Resources

GitHub Repository: react-hook-lab
react-hook-lab: npm package
Connect with me on LinkedIn: Saurav Pandey

Originally published on my blog. You can read the alternative breakdown here.

The Physics Under The Protocols: A Developer's Tour Of Electromagnetism

Fri, 04 Sep 2026 14:25:09 +0000

Most of us debug things that ride on electromagnetic waves all day without ever looking at the physics underneath. This is the short version, written for developers, of why radio, WiFi and visible light are literally the same phenomenon.

One Force, Not Two

Until 1820 electricity and magnetism were treated as unrelated curiosities. Then Hans Christian Oersted noticed a compass needle deflect when current ran through a nearby wire. That was the entire experiment, and it meant the two could not be independent.

Andre-Marie Ampere had the mathematics for the force between current carrying wires within months. In the 1830s Michael Faraday showed the reverse, that a changing magnetic field induces a current in a nearby wire.

In the 1860s James Clerk Maxwell turned all of it into four equations. They predicted a self sustaining wave travelling at roughly 3 x 10^8 meters per second, a number already known from optics as the speed of light. Maxwell had derived light from equations written about wires and magnets. Heinrich Hertz generated and detected radio waves in 1887 and confirmed it.

Why The Spectrum Is Continuous

Radio, microwave, infrared, visible light, ultraviolet, X-rays and gamma rays are one phenomenon sliced by frequency. Nothing physical changes at the boundaries between them, only the wavelength and what that wavelength happens to interact with.

Once that clicks, a lot of separate networking facts collapse into one. Antenna length tracking wavelength, why 2.4 GHz passes through a wall better than 5 GHz, why interference shows up where two links share a band. Same equations, different numbers.

Induction Is The Part You Touch Every Day

A changing magnetic field induces a current in any nearby conductor. That is the transformer inside your power brick and the wireless charging pad on your desk.

It is also crosstalk. A fast switching signal trace induces current in the trace beside it whether you wanted that or not, which is Faraday's law showing up as a bug rather than a feature. Ground planes and spacing rules exist because of a discovery from the 1830s.

Ohm's Law Is Still The Fastest Debugging Tool

V = IR. Voltage is the potential difference pushing charge, current is the rate that charge flows, resistance is what opposes it. Measure any two and the third follows.

For hardware faults that is often quicker than reaching for a logic analyzer. A multimeter tells you whether the rail is at voltage, whether current is being drawn, and whether something in the path has gone open or short, and that narrows most problems before you ever look at a waveform.

What Makes This Worth Reading Twice

The pattern is worth borrowing beyond physics. Two domains looked separate, one experiment linked them, and a single mathematical description then covered both. That description went on to predict something nobody had put into it, and the prediction turned out to be a number already measured in a different field.

A description reorganizes what you already know. A model tells you something you did not.

The full walkthrough, covering charge and current, electric and magnetic fields, the four equations, the spectrum, induction and circuits, is in this guide to how electromagnetism works.

How Can an App Reach a Database That the Internet Cannot?

Mon, 31 Aug 2026 14:41:50 +0000

In the previous article, we answered a fundamental question:

How does one server find another server?

We explored DNS, Private DNS, and Service Discovery the mechanisms that turn something like:

postgres.internal.company

into a reachable destination inside a network.

But finding a server is only half of the story.

Knowing where a server is doesn't automatically mean you're allowed to connect to it.

That leads us to a more interesting question.

Most developers eventually learn this architecture:

User
  ↓
Application
  ↓
Database

But how does this actually work at the network level?

If the application can connect to PostgreSQL, why can't someone on the Internet connect to the same database?

This sounds like a simple networking question.

It isn't.

The answer involves:

Network routing
Public and private subnets
VPCs
Security groups
Firewall rules
Network isolation
Access boundaries
Defense in depth

And these concepts ultimately determine something much bigger:

Which systems are allowed to talk to which other systems?

That's one of the most important questions in production infrastructure.

Because there is a critical difference between:

Can I find the server?

and:

Can I reach the server?

And an even more important difference between:

Can I reach the server?

and:

Am I allowed to connect?

In the previous article, we focused on finding the destination.

In this article, we'll focus on controlling access to that destination.

Let's break it down.

The Architecture We Usually See

Imagine a typical SaaS application:

                    Internet
                        │
                        ▼
                 Load Balancer
                        │
                        ▼
                  Application
                        │
                        ▼
                   PostgreSQL

The application needs the database.

Customers don't.

That distinction is extremely important.

The customer needs:

Internet
   ↓
Application

The application needs:

Application
   ↓
Database

But there should usually be no direct path like this:

Internet
   ↓
Database

This is where cloud networking starts becoming interesting.

The First Principle: Not Everything Needs to Be Reachable

A common mistake in infrastructure design is thinking:

If a service needs to work,
it should be reachable.

Modern infrastructure follows almost the opposite principle:

Make only what needs to be reachable,
reachable.

For example:

Public
  │
  ├── Load Balancer
  │
  └── API Gateway

Private
  │
  ├── Application Servers
  ├── Background Workers
  ├── Redis
  └── PostgreSQL

The database doesn't need to accept connections from the public Internet.

So why expose it?

You don't.

This simple decision dramatically reduces the attack surface.

Public Subnet vs Private Subnet

Inside a cloud network such as a VPC, resources are commonly organized into different network boundaries.

Two of the most important concepts are:

Public Subnet
Private Subnet

Think about a building.

There might be:

Public Area
     ↓
Reception
Meeting Room
Waiting Area

And deeper inside:

Restricted Area
     ↓
Operations
Finance
Infrastructure
Records

Not everyone who can enter the building should be able to enter every room.

Cloud networks work with a similar principle.

What Is a Public Subnet?

A public subnet is a subnet whose routing configuration provides a path toward an Internet Gateway.

Resources placed there can be Internet-facing when their own network configuration also permits it for example, when they have a public IP or are exposed through a public load balancer.

Typical examples include:

Load Balancers
Reverse Proxies
Internet-facing Web Servers
Bastion Hosts

A simplified architecture might look like:

                 Internet
                     │
                     ▼
              Internet Gateway
                     │
                     ▼
               Public Subnet
                     │
                     ▼
              Load Balancer

This is where Internet-facing traffic enters the system.

What Is a Private Subnet?

A private subnet is designed for resources that should not be directly reachable from the public Internet.

Typical resources include:

Application Servers
PostgreSQL
MySQL
Redis
RabbitMQ
Kafka
Background Workers
Internal Services

A simplified architecture:

Internet
   ✖
   │
   ▼
Private Subnet
   │
   ├── Application
   ├── Redis
   └── PostgreSQL

The important idea is not:

"Nobody can access these machines."

It is:

"They are not directly reachable from the public Internet."

That distinction matters.

Private Does Not Mean Isolated

This is one of the most common misunderstandings.

Many developers hear:

Private Subnet

and think:

Nothing can connect to it.

Not true.

A private subnet can communicate with other resources inside the same VPC.

For example:

Application Server
10.0.1.10
       │
       ▼
PostgreSQL
10.0.2.20

Both resources may exist inside:

VPC
10.0.0.0/16

The traffic can remain inside the cloud network.

It doesn't need to travel across the public Internet.

So How Does the App Reach the Database?

Suppose:

Application Server
10.0.1.10

needs to connect to:

PostgreSQL
10.0.2.20:5432

The application creates a TCP connection:

10.0.1.10
      │
      │ TCP :5432
      ▼
10.0.2.20

The VPC routing system determines how packets should move between those network destinations.

If the route exists and the relevant security controls permit the traffic, the connection succeeds.

There is no requirement for the database to have a public IP.

In fact, keeping the database private is usually the safer design.

Then What Stops Everyone Else?

This is where Security Groups become important.

Routing answers:

Where should this packet go?

Security controls answer:

Is this traffic allowed?

These are different questions.

Security Groups: The Access Control Layer

In AWS, a Security Group acts as a stateful virtual firewall associated with resources such as EC2 instances and certain managed services.

Imagine a building.

The subnet is the area of the building.

The security group is the access control at the door.

The database exists.

The network path may exist.

But access can still be restricted.

For PostgreSQL, the standard port is:

A dangerous rule might look like:

Inbound

Port: 5432
Source: 0.0.0.0/0

That effectively allows connection attempts from anywhere that can reach the database.

That is rarely what you want for a production database.

The Better Rule

Instead of:

Allow everyone

define:

Allow application servers

For example:

Database Security Group
        │
        └── Inbound
              │
              ├── Protocol: TCP
              ├── Port: 5432
              └── Source: App Security Group

Now the access relationship becomes:

Internet User
      ✖

Random Server
      ✖

Unrelated Service
      ✖

Application Server
      ✔

This is much more meaningful than simply allowing a large IP range.

Why Security Group References Matter

Consider an application running on multiple servers.

Initially:

10.0.1.10

So someone might configure:

Allow 10.0.1.10 → PostgreSQL:5432

Then autoscaling happens.

Now there are:

10.0.1.10
10.0.1.11
10.0.1.12
10.0.1.13

Tomorrow there may be twenty.

The infrastructure is dynamic.

Hardcoding individual IP addresses creates unnecessary operational complexity.

Instead, define an application security group:

app-sg

Attach it to application servers.

Then configure the database:

db-sg

Inbound:
5432
Source:
app-sg

Now the rule expresses the actual architectural relationship:

Application Layer
       │
       │ allowed
       ▼
Database Layer

The exact server IP becomes less important.

Network Access Is a Chain of Decisions

A database connection isn't simply:

Can I ping the database?

Multiple layers can influence whether traffic succeeds.

Conceptually:

Application
    │
    ▼
DNS Resolution
    │
    ▼
Route
    │
    ▼
Network ACL
    │
    ▼
Security Group
    │
    ▼
Database Listener
    │
    ▼
PostgreSQL

If any required layer is incorrectly configured, the connection can fail.

This is why production networking can feel confusing.

There isn't always one single "firewall."

There are multiple boundaries.

A Production-Style Architecture

A more realistic architecture might look like this:

                         Internet
                             │
                             ▼
                    ┌─────────────────┐
                    │  Load Balancer  │
                    │     Public      │
                    └────────┬────────┘
                             │
                             ▼
                    ┌─────────────────┐
                    │ Application     │
                    │    Servers      │
                    │    Private      │
                    └────────┬────────┘
                             │
                  ┌──────────┴──────────┐
                  │                     │
                  ▼                     ▼
          ┌──────────────┐      ┌──────────────┐
          │    Redis     │      │  PostgreSQL  │
          │   Private    │      │   Private    │
          └──────────────┘      └──────────────┘

Notice the boundaries.

The Internet can reach the load balancer.

The load balancer can reach the application.

The application can reach PostgreSQL.

But the Internet does not get a direct path to PostgreSQL.

This Is Defense in Depth

Now imagine the application itself contains a vulnerability.

An attacker manages to compromise a public-facing component.

A poorly designed network might look like:

Compromised Server
       │
       ├── Database ✔
       ├── Redis ✔
       ├── Internal APIs ✔
       └── Everything Else ✔

The blast radius becomes enormous.

A better architecture might look like:

Compromised Server
       │
       ├── Database ✔
       ├── Redis ✖
       ├── Internal Service ✖
       └── Other Systems ✖

The attacker may still have compromised one component.

But the compromise doesn't automatically become a compromise of the entire environment.

That is the value of segmentation.

Security Is About Blast Radius

One of the most useful ways to think about infrastructure security is:

What happens if one component is compromised?

Not:

Can anything ever be hacked?

That second question is unrealistic.

Production systems should be designed with the assumption that individual components can fail or become compromised.

The goal is to limit the damage.

For example:

Internet
   │
   ▼
Public Service
   │
   ▼
Private Application
   │
   ▼
Private Database

Each layer has a limited set of allowed relationships.

This creates smaller blast radiuses.

Why This Matters Beyond Security

Network isolation isn't only about preventing attackers.

It also improves operational control.

Suppose a database is publicly accessible.

Then many different systems can potentially attempt to connect:

Internet
   │
   ├── Bots
   ├── Scanners
   ├── Attackers
   ├── Unknown Services
   └── Legitimate Clients

Now the database must deal with traffic it never needed in the first place.

A private database changes the model:

Application Layer
       │
       ▼
Database

The allowed communication becomes explicit.

That improves:

Security
Reliability
Troubleshooting
Operational visibility
Compliance
Change management

The Business Impact Is Hidden in the Architecture

A network diagram may look purely technical.

But every boundary represents a business decision.

Consider a database containing:

Customer Accounts
Payment Records
Orders
Personal Information
Internal Business Data

If that database is accidentally exposed, the consequences can extend far beyond engineering:

Misconfiguration
      ↓
Unauthorized Access
      ↓
Data Exposure
      ↓
Incident Response
      ↓
Downtime / Investigation
      ↓
Customer Impact
      ↓
Financial & Reputation Cost

The infrastructure decision happened at the technical layer.

The consequences don't stay there.

This is why architecture is ultimately connected to business continuity.

"Nobody Knows the Database IP" Is Not Security

Another common assumption is:

Nobody knows my database IP.

Therefore:
I'm safe.

That's security through obscurity.

A better assumption is:

Assume the attacker knows the address.

Then ask:

Can they establish a connection?

If the answer is:

No route
+
No public exposure
+
Security group denies access

then knowing the address doesn't help much.

The important boundary is not secrecy.

It is reachability and authorization.

Public Exposure vs Private Access

Let's compare the two models.

Public Database

Internet
    │
    ▼
Public IP
    │
    ▼
PostgreSQL:5432

The database is directly exposed to Internet traffic.

Even if authentication is strong, the attack surface is unnecessarily large.

Private Database

Internet
    │
    ✖
    │
    ▼
Private Network
    │
    ▼
PostgreSQL:5432

And:

Application
    │
    ✔
    ▼
PostgreSQL:5432

The database only needs to serve the application.

So the network should reflect that requirement.

A Simple Mental Model

Think of your infrastructure as a building.

                 STREET
                   │
                   ▼
             Public Lobby
                   │
                   ▼
             Employee Area
                   │
                   ▼
                Vault

The public can enter the lobby.

Employees can enter restricted areas.

Only authorized systems can reach the vault.

Now translate that into cloud architecture:

                 Internet
                    │
                    ▼
              Public Subnet
                    │
                    ▼
          Private Application Layer
                    │
                    ▼
            Private Database Layer

And Security Groups define:

Who can move between the layers.

That's the mental model worth remembering.

The Bigger Engineering Principle

A strong production architecture doesn't ask:

How do we make everything communicate?

It asks:

What actually needs to communicate?

Then it creates the smallest set of allowed paths.

For example:

Load Balancer
      │
      ▼
Application
      │
      ├──────► PostgreSQL
      │
      └──────► Redis

But:

Internet ─────X────► PostgreSQL

Internet ─────X────► Redis

Redis ─────────X────► PostgreSQL

unless those connections are explicitly required.

This is the principle of least privilege applied to networking.

Key Takeaways

Public subnets are designed for Internet-facing resources.
Private subnets are used for resources that should not be directly reachable from the public Internet.
A private subnet does not mean the resources inside it cannot communicate.
VPC routing enables communication between private resources when routes exist.
Security Groups control which traffic is allowed.
Databases generally should not be directly exposed to the public Internet.
Security Group references can express application-to-database relationships more effectively than hardcoded IP addresses.
Network segmentation limits blast radius when a component is compromised.
Security is not about making systems unreachable.
Security is about making only the necessary systems reachable by the necessary systems.
Infrastructure decisions can directly affect security, reliability, compliance, operational cost, and customer trust.

The most important idea is simple:

Great infrastructure is not about
making everything reachable.

Great infrastructure is about
making only the right things reachable.

How Does One Server Find Another Server? DNS, Private DNS, and Service Discovery Explained

Fri, 28 Aug 2026 16:58:06 +0000

Hey developers! 👋

Welcome back to our networking and infrastructure deep-dive series.

In the previous article

we learned something surprising:

Two servers inside AWS, Azure, GCP, or a private datacenter can communicate without touching the public internet.

No ISP.

No public IP.

No internet routing.

Just private networking.

But that raises a much bigger question.

A question every backend developer eventually encounters.

The Mystery Nobody Talks About

Imagine you have:

Web Server
    |
    |
    ▼
PostgreSQL Server

Your application needs to connect to PostgreSQL.

Simple.

Right?

Not really.

Because the web server doesn't magically know:

Where PostgreSQL is.

Servers are not humans.

They cannot read dashboards.

They cannot open AWS Console.

They cannot browse Kubernetes UI.

So the real question becomes:

How does one server discover another server?

This seemingly simple question led to the creation of:

DNS
Private DNS
Service Discovery
Consul
Eureka
Kubernetes DNS
Cloud Map
Service Meshes

And ultimately became one of the most important problems in distributed systems.

Today we're going deep into that rabbit hole.

Imagine a New City

Suppose you move into a new city.

You need to find:

Hospital
Bank
Police Station
Restaurant

Do you memorize every building's GPS coordinates?

Of course not.

Instead you use:

Names

Such as:

city-hospital.com

instead of:

104.22.18.150

Computers do exactly the same thing.

Humans prefer names.

Networks use IP addresses.

Something must translate between them.

That something is DNS.

DNS: The Internet's Phonebook

DNS stands for:

Domain Name System

Its job is simple:

Name -> IP Address

Example:

google.com

↓

142.250.x.x

When you visit:

https://google.com

your computer first asks:

What's the IP address of google.com?

DNS replies:

142.250.x.x

Only then can the connection begin.

Without DNS:

The internet would be a giant spreadsheet of IP addresses.

Nobody wants that.

What Actually Happens?

When your browser requests:

google.com

the flow looks like:

Browser
   |
   ▼
DNS Resolver
   |
   ▼
Root DNS
   |
   ▼
.com Nameserver
   |
   ▼
Google Nameserver
   |
   ▼
IP Address Returned

Then:

Browser
   |
   ▼
Google Server

Connection established.

This process often completes in milliseconds.

Billions of times every day.

But Cloud Infrastructure Has a Problem

Public DNS works great for public websites.

But what about:

Backend API
Redis
PostgreSQL
RabbitMQ
Elasticsearch

These services are not public.

In fact:

They should NEVER be public.

Example:

api.company.com

can be public.

But:

postgres.company.com

should almost never be exposed to the internet.

So where do we keep internal server names?

This is where Private DNS enters the picture.

Private DNS: The Hidden Phonebook

Think of Private DNS as:

An internal company directory.

Only employees can access it.

Not outsiders.

Example:

db.internal
redis.internal
auth.internal
payments.internal

These names resolve only inside the private network.

Outside users see:

Nothing.

Inside AWS this is common.

Example:

ip-10-0-4-25.ec2.internal

db.production.internal

Only resources inside the VPC can resolve these names.

The public internet has no idea they exist.

Real Production Example

Suppose you're building an e-commerce platform.

Architecture:

Internet
    |
    ▼
Load Balancer
    |
    ▼
Web Servers
    |
    ▼
API Service
    |
    ├────────► PostgreSQL
    |
    ├────────► Redis
    |
    └────────► RabbitMQ

Question:

How does API Service find PostgreSQL?

Do we hardcode:

10.0.12.55

inside the application?

Never.

Because servers change.

Instances restart.

Containers move.

Databases failover.

IP addresses evolve.

Hardcoded IPs become operational nightmares.

Instead:

DATABASE_HOST = "postgres.internal"

Now infrastructure can move PostgreSQL anywhere.

DNS updates.

Application remains unchanged.

Beautiful.

The IP Address Problem

Modern infrastructure is dynamic.

Very dynamic.

Consider Kubernetes.

A container crashes.

A new container starts.

The new container may receive:

Completely different IP

within seconds.

Imagine every service storing IPs manually.

The system would collapse.

This is why names matter.

Names remain stable.

IPs do not.

Enter Service Discovery

DNS solved:

Find a machine

Service Discovery solves:

Find a service

Those sound similar.

They are not.

Let's see why.

The Microservice Nightmare

Imagine:

User Service

Order Service

Payment Service

Notification Service

Inventory Service

Recommendation Service

Each service runs:

Multiple Instances

Example:

Payment Service

payment-1
payment-2
payment-3
payment-4

Now User Service wants Payment Service.

Which instance should it choose?

payment-1 ?
payment-2 ?
payment-3 ?
payment-4 ?

Hardcoding doesn't work.

Static DNS doesn't fully solve it.

We need something smarter.

What Service Discovery Actually Does

A service registry keeps track of:

Who exists
Where they are
Whether they are healthy

Think of it like:

Air Traffic Control

for services.

Every service announces:

I'm alive.
Here's my address.

Registry stores that information.

Other services ask:

Where is Payment Service?

Registry responds:

payment-2
payment-3
payment-4

Now requests can flow.

Netflix Solved This Years Ago

When Netflix moved to microservices they faced a huge challenge.

Thousands of services.

Millions of requests.

Servers constantly scaling.

They created:

Eureka

A service discovery platform.

Services register themselves.

Other services discover them dynamically.

Without manual configuration.

This became one of the foundational patterns of cloud-native architecture.

Kubernetes: Service Discovery on Steroids

Kubernetes has built-in service discovery.

Suppose you deploy:

payment-service

with:

4 Pods

Kubernetes automatically creates:

payment-service.default.svc.cluster.local

Your application simply uses:

PAYMENT_URL = "http://payment-service"

No IP required.

No server management.

No lookup tables.

Kubernetes DNS handles everything.

Behind the scenes:

payment-service
        |
        ▼
Cluster DNS
        |
        ▼
Healthy Pods

Magic?

Not really.

Just extremely sophisticated automation.

What Happens During a Request?

Imagine:

Order Service

calls:

Payment Service

Flow:

Order Service
       |
       ▼
DNS Query
       |
       ▼
Cluster DNS
       |
       ▼
Payment Service Endpoints
       |
       ▼
Healthy Pod Selected
       |
       ▼
Request Sent

All this happens in milliseconds.

Most developers never see it.

Yet every request depends on it.

Health Checks Change Everything

Modern service discovery isn't just:

Where is the service?

It also asks:

Is the service healthy?

Suppose:

payment-3

crashes.

Registry detects failure.

Immediately removes it.

Now traffic goes only to:

payment-1
payment-2
payment-4

No code changes required.

No deployment required.

Infrastructure heals itself.

This is one of the superpowers of modern cloud systems.

DNS vs Service Discovery

Many engineers confuse them.

Let's simplify.

Feature	DNS	Service Discovery
Finds Machines	Yes	Yes
Finds Services	Limited	Yes
Tracks Health	No	Yes
Dynamic Scaling	Limited	Excellent
Cloud Native	Partial	Yes
Microservices Friendly	Partial	Excellent

Think of DNS as:

A phonebook

Think of Service Discovery as:

A live GPS system with traffic updates.

Huge difference.

AWS Example

AWS provides:

AWS Cloud Map

Services register themselves.

Applications discover services dynamically.

Instead of:

10.0.22.17

you use:

payment.production.internal

AWS continuously keeps records updated.

Your applications stay clean.

Infrastructure stays flexible.

The Hidden System Every Developer Uses

Whenever your application connects to:

Database
Cache
Queue
API
Microservice

one of the following is usually working behind the scenes:

DNS

Private DNS

Service Discovery

Without them:

Modern cloud architecture would be impossible.

Not difficult.

Impossible.

Visual Mental Model

Application
     |
     ▼
Service Name

(payment-service)

     |
     ▼
DNS / Service Discovery

     |
     ▼
Healthy Instance

(payment-2)

     |
     ▼
TCP Connection

     |
     ▼
Response

Simple.

Powerful.

Cloud Native.

Why System Designers Care

Junior developers often think:

Database Host = Some String

System designers think:

How is that string resolved?

Who owns it?

What happens during failover?

How is health tracked?

How does scaling affect discovery?

How quickly do updates propagate?

These questions separate:

Application Development

from

Infrastructure Engineering

Understanding service discovery is one of the first steps toward thinking like a platform engineer, DevOps engineer, cloud architect, or distributed systems designer.

TL;DR Quick Recap

Servers communicate using IP addresses.
Humans prefer names.
DNS translates names into IP addresses.
Private DNS provides internal-only naming.
Modern infrastructure avoids hardcoded IPs.
Service Discovery tracks service locations dynamically.
Kubernetes provides built-in service discovery.
Healthy instances are automatically discovered.
Failed instances are automatically removed.
Every modern cloud platform depends heavily on these mechanisms.

Final Thoughts: The Invisible Map of the Cloud 🗺️

Most developers spend years writing:

DATABASE_HOST="postgres"

without asking:

Who told the application where postgres is?

Behind that tiny configuration value sits an enormous ecosystem:

DNS Servers
Private DNS
Service Registries
Health Checks
Load Balancers
Cloud Networking
Kubernetes Controllers

All working together to answer one deceptively simple question:

"Where is the thing I'm trying to talk to?"

And surprisingly, that question powers almost every distributed system on Earth.

In the next article, we'll go even deeper:

How Does Traffic Know Which Server Should Receive the Request?

Load Balancers → Reverse Proxies → Traffic Routing → Health Checks

Because finding a service is only half the story.

Choosing the right instance is where things get really interesting. 🚀

Internet-Free Infrastructure: How Two Servers Talk Without Using the Internet

Tue, 25 Aug 2026 17:21:06 +0000

Imagine you're building a SaaS platform.

Nothing unusual.

A web application.

A PostgreSQL database.

A Redis cache.

Everything runs in the cloud.

The architecture looks something like this:

Users
  ↓
Application Server
  ↓
PostgreSQL

Simple.

A user sends a request.

The application queries the database.

The database responds.

The application returns data.

Feature shipped.

Customers happy.

Everyone moves on.

For a while.

The Question Nobody Asks

Most engineers focus on:

Application Logic

Database Queries

API Design

But infrastructure engineers eventually ask a different question:

How does the application server actually reach the database server?

Not conceptually.

Literally.

How does one machine know where another machine is?

How does a packet travel from one server to another?

And perhaps the most surprising question:

If both servers live in the cloud, why doesn't their communication go through the Internet?

The Common Misconception

Many people imagine cloud infrastructure like this:

Application Server
        ↓
     Internet
        ↓
Database Server

It seems reasonable.

After all, both servers exist somewhere inside AWS, Azure, or Google Cloud.

Surely the traffic goes through the Internet.

Right?

Actually, no.

In most production systems, internal communication never touches the public Internet.

Instead, it looks like this:

Application Server
        ↓
 Private Network
        ↓
Database Server

No public Internet.

No ISP.

No external routers.

No public IP addresses.

Just private infrastructure.

This distinction matters because it changes everything about:

Security
Performance
Reliability
Cost
Scalability

To understand why, we need to start with the first building block.

The VPC.

The Cloud Is A Giant City

Imagine AWS as a massive country.

Inside that country:

Netflix

Airbnb

Stripe

Shopify

Your Startup

Thousands of Others

All of them are running servers.

All of them are storing data.

All of them are deploying applications.

Now imagine there were no boundaries.

No isolation.

No separation.

Every server could see every other server.

That would be a security nightmare.

Cloud providers solve this problem using something called a:

Virtual Private Cloud
(VPC)

Think of a VPC as:

Your own private city
inside a giant country.

The cloud provider owns the country.

You own the city.

Inside that city:

Your servers can communicate
Your databases can communicate
Your caches can communicate
Other companies cannot access them

The first thing cloud infrastructure gives you is not a server.

It's a private network.

Why Infrastructure Starts With A Network

New engineers often think infrastructure begins here:

EC2 Instance

Virtual Machine

Server

It doesn't.

Infrastructure usually begins here:

VPC

Because servers without networks are useless.

Imagine buying a house.

But there are:

No roads

No addresses

No transportation

The house exists.

But nobody can reach it.

Servers have the same problem.

Before machines can communicate, they need a network.

The VPC creates that network.

The Next Problem

Suppose your company grows.

Now you have:

Application Servers

Database Servers

Redis

Background Workers

Message Queues

Monitoring Systems

Admin Tools

Everything lives inside one VPC.

At first this sounds convenient.

Until security enters the conversation.

Should a database be reachable from everywhere?

Probably not.

Should every server have Internet access?

Probably not.

Should internal systems be exposed publicly?

Definitely not.

This is where subnets appear.

Subnets Are Neighborhoods

If a VPC is a city:

VPC = City

Then:

Subnet = Neighborhood

A company might create:

VPC
│
├── Public Subnet
│
├── Application Subnet
│
└── Database Subnet

Each subnet serves a purpose.

For example:

Public Subnet

Load Balancer

Private Application Subnet

App Server 1
App Server 2
App Server 3

Private Database Subnet

PostgreSQL
Redis

Notice something important.

The database sits deeper inside the infrastructure.

Further away from the Internet.

This is intentional.

Because good infrastructure is built around reducing exposure.

The Database Doesn't Need The Internet

Many founders are surprised by this.

A database usually doesn't need users.

A database needs applications.

That's a completely different requirement.

Consider:

Customer
    ↓
Application
    ↓
Database

The customer never talks directly to PostgreSQL.

Only the application does.

So exposing the database publicly creates risk without creating value.

This is why production databases often live in private subnets.

The database can still be reached.

But only by trusted systems.

Every Server Gets A Private Address

Now imagine an application server wants to reach PostgreSQL.

How does it find the database?

The same way you find a building.

Addresses.

Every server receives an IP address.

Example:

Application

10.0.1.10

Database

10.0.2.20

These are private IP addresses.

Not public ones.

Nobody on the Internet can reach them.

But machines inside the VPC can.

Now the application knows:

Database

10.0.2.20

Problem solved?

Not quite.

Knowing an address isn't enough.

Knowing The Address Doesn't Create A Path

Imagine someone gives you:

221B Baker Street

Great.

You know the destination.

But how do you get there?

You need roads.

Networks have the same problem.

An IP address tells you:

Where

But not:

How

That responsibility belongs to routing.

Routing Is The GPS Of The Cloud

Every network contains routing rules.

These rules answer one question:

Where should this packet go next?

A route table might contain:

Destination      Target

10.0.0.0/16      Local

Meaning:

Any traffic
inside this VPC
stays inside this VPC

Now imagine:

Application

10.0.1.10

sending a request to:

Database

10.0.2.20

The network checks the routing table.

Destination?

10.0.2.20

Result:

Inside VPC

Therefore:

Deliver Locally

The packet never leaves the cloud network.

The Internet is never involved.

The communication happens entirely inside private infrastructure.

The Request's Actual Journey

When the application queries PostgreSQL:

SELECT * FROM users;

What really happens is:

Application
   ↓
Private IP
   ↓
Route Table
   ↓
Database Subnet
   ↓
Database Server

No Internet.

No DNS lookup to the public Internet.

No external networking providers.

Just internal routing.

This is why internal communication is usually:

Faster
More secure
More predictable
Less exposed to external failures

Why This Matters To Founders

At first glance this sounds like technical trivia.

It's not.

Because infrastructure decisions directly affect business outcomes.

Imagine two architectures.

Architecture A

Application
     ↓
Internet
     ↓
Database

Architecture B

Application
     ↓
Private Network
     ↓
Database

The second architecture provides:

Better security
Lower attack surface
Lower latency
Fewer compliance concerns
Better scalability

The customer never notices.

But the company benefits every day.

This is one of the reasons mature SaaS platforms invest heavily in infrastructure design.

Not because customers ask for VPCs.

Because customers expect reliability.

The Most Important Lesson

When most people think about cloud infrastructure, they think about servers.

Experienced engineers think about networks.

Because before applications communicate:

Networks must exist.

Before databases respond:

Routes must exist.

Before systems scale:

Infrastructure boundaries must exist.

The Internet is only one network.

Most production systems spend far more time communicating inside private networks than across the public Internet.

And understanding that idea is the first step toward understanding modern cloud infrastructure.

Frequently Asked Questions

What is a VPC?

A Virtual Private Cloud (VPC) is an isolated private network inside a cloud provider where your infrastructure resources can communicate securely.

What is a subnet?

A subnet is a smaller network segment inside a VPC used to organize and isolate infrastructure resources.

Why do servers use private IP addresses?

Private IP addresses allow internal communication without exposing systems directly to the public Internet.

Does traffic between servers always go through the Internet?

No.

In most cloud architectures, communication between internal services stays inside the provider's private network.

What is a route table?

A route table contains rules that determine where network traffic should be sent.

Why are databases usually placed in private subnets?

Because databases typically only need to communicate with application servers, not with public users.

Key Takeaways

Most production server-to-server communication never touches the public Internet.
A VPC creates an isolated private network inside the cloud.
Subnets divide a network into smaller security and operational boundaries.
Servers communicate using private IP addresses.
Route tables determine how packets travel through the network.
Security starts with network design, not application code.
Cloud infrastructure is fundamentally a networking problem before it becomes a server problem.
Understanding VPCs, subnets, private IPs, and routes is the foundation of modern cloud architecture.

HttpClient Socket Exhaustion

Mon, 24 Aug 2026 10:37:13 +0000

Your .NET API is Slowly Dying (And You Don't Even Know It)

Last month, our production system started timing out randomly. No errors. No warnings. Just... slow death.
After 3 sleepless nights and diving through 60+ microservices, I found the culprit:

var client = new HttpClient(); // This single line
Here's what was happening:
Every HTTP call was creating a NEW TCP socket. Under load, we exhausted the system's connection pool. Requests started queuing. Response times went from 200ms to 30+ seconds.

The Silent Killer:
• ✅ Your code compiles fine
• ✅ Your tests pass
• ✅ It works in dev/staging
• ❌ It crashes in production under real load

The Fix That Saved Our SLA:

// In Startup.cs
`services.AddHttpClient("MyService", client => {

client.Timeout = TimeSpan.FromSeconds(120);

}) .ConfigurePrimaryHttpMessageHandler(() => new SocketsHttpHandler {

PooledConnectionLifetime = TimeSpan.FromMinutes(2),
PooledConnectionIdleTimeout = TimeSpan.FromMinutes(5),
MaxConnectionsPerServer = 20,
AutomaticDecompression = DecompressionMethods.GZip | DecompressionMethods.Deflate

});`

`// In your service
public class MyService {

private readonly IHttpClientFactory _clientFactory;    
public MyService(IHttpClientFactory clientFactory) {
    _clientFactory = clientFactory;
}    
public async Task<string> GetDataAsync() {
    var client = _clientFactory.CreateClient("MyService");
    // Use the client
}

}
`

The Results:
95% reduction in connection failures
⚡ 40% improvement in throughput
Prevented potential revenue loss from timeouts

The Lesson:
IHttpClientFactory isn't just a "best practice" - it's a production survival tool.
Microsoft documented this in 2018, but I still see this anti-pattern EVERYWHERE.
Have you been bitten by socket exhaustion?

Share your battle story in comments

#performance #dotnet #csharp #softwareengineering #productionissues #microservices #debugging #azure #performanceoptimization #lessonslearned #techleadership

Social Networking Website Development: A Complete Guide

Fri, 21 Aug 2026 14:30:35 +0000

Everyone wants to build the next big social platform. But most people who start down that road hit the same wall pretty fast — they don't know where to begin, what features actually matter, or how much the whole thing is going to cost.

If you've been sitting on an idea for a community platform, a niche network, or even a full-scale social media site, this guide is for you. We're breaking down everything from planning and features to tech choices and launch strategy, so you can move forward with confidence instead of guessing your way through it.

What Is a Social Networking Website (and Why Build One)?

A social networking website is an online platform that lets users create profiles, connect with others, share content, and engage within a community. Think beyond just Facebook or Instagram. Niche social networks built around fitness communities, alumni groups, professional industries, or local neighborhoods are thriving right now.

The demand for focused, community-driven platforms has never been higher. People are tired of noisy, algorithm-heavy mega-platforms and actively looking for spaces where they actually belong. That's a real opportunity for founders and businesses willing to build something intentional.

Plan Before You Build

Skipping the planning phase is the single biggest reason social platforms fail before they ever find an audience.

Before you write a line of code or hire a developer, get clear on these fundamentals:

Who is your audience? Define exactly who the platform is for and what problem it solves for them. The more specific, the better. "Professionals in renewable energy" beats "anyone interested in green living."
What is your MVP? Your minimum viable product should include only the features users absolutely need to get value from day one. Resist the urge to build everything at once.

What is your budget? Factor in development, hosting, marketing, and at least six months of operational costs before you launch.

What are your legal requirements? Privacy policies, terms of service, GDPR compliance, and content moderation rules need to be in place before users sign up.

Taking the time here saves you from expensive course corrections later.

Core Features Every Social Network Needs

Whether you're building a small niche community or a large-scale platform, certain features are non-negotiable. These are the building blocks of any solid social networking website development project.
User Profiles and Onboarding

Profiles are how people represent themselves on your platform. They should be easy to set up and immediately useful. A good onboarding flow gets new users to value within the first five minutes, which is the window that determines whether they stick around.

News Feed and Content Posting

The feed is the heartbeat of any social platform. Users need to be able to post text, images, and video, and they need a feed that surfaces relevant content from people and groups they follow. Get this right and you create a reason to come back every day.
Messaging and Notifications

Real-time messaging between users is a baseline expectation now. Pair that with smart notifications (in-app, email, and push) and you start building habitual engagement. Nobody checks a platform that never tells them something is happening.

Groups and Communities

Groups give users a reason to gather around specific topics. They're one of the highest-engagement features on any social platform because they create belonging. Build groups well and your users will do a lot of the community-building work for you.
Search and Discovery

If users can't find people, content, or communities easily, they leave. A strong search function and smart discovery tools (suggested friends, trending topics, recommended groups) keep the network feeling alive and growing.

Choosing Your Development Approach

This is the most consequential decision you'll make. There are three main paths, and each comes with real trade-offs.

Custom Development

Building from scratch gives you maximum control and flexibility. It also costs between $50,000 and $500,000 and takes anywhere from nine to eighteen months. This makes sense for funded startups with complex, unique requirements. For most founders, it's overkill at the start.
White-Label Scripts

A white-label social network script is a pre-built, fully functional platform you can rebrand, customize, and deploy as your own. Costs typically run between $500 and $5,000 for the license, and you can go from purchase to live platform in a matter of weeks. You get full source code ownership, which means you're not renting someone else's software.
SaaS Platforms

Software-as-a-service solutions let you launch without touching code at all. They're great for testing an idea quickly, but you give up data ownership, customization depth, and flexibility. If you outgrow the platform, migrating is painful.

For most people starting out, white-label development hits the sweet spot between speed, cost, and control.

The Tech Stack Behind a Social Network

If you're going the custom route, your technology choices shape everything about how your platform performs and scales.

Backend: Laravel (PHP) is the most popular choice for social platforms and what most white-label scripts are built on. Node.js is strong for real-time features. Django works well if your platform leans heavily on data or machine learning.

Frontend: React.js is widely used and has a massive ecosystem. Vue.js pairs particularly well with Laravel and has a gentler learning curve. Next.js adds server-side rendering, which helps with SEO and initial load times.

Database and infrastructure: MySQL or PostgreSQL for structured user data, Redis for caching and real-time data, and Elasticsearch if you need powerful search. For media storage, AWS S3 or DigitalOcean Spaces handle photos and videos at scale. WebSockets (via Pusher or Socket.io) power real-time messaging and live notifications.

How to Launch Without an Empty Network

The empty room problem kills more social platforms than bad code ever will. Nobody wants to join a platform where nothing is happening.

Before you open your doors publicly, spend two to four weeks running a soft launch with a seed community of 50 to 200 founding members you've invited personally. Pre-populate the platform with quality content. Create active discussions. Assign community moderators. Give founding members something special, like exclusive badges or lifetime premium access, to build loyalty from day one.
When you do open publicly, you're launching into a living, breathing community, not a ghost town.

Monetization Models That Actually Work

Most successful social networks don't rely on a single income stream. Here are the approaches that perform best:

Premium subscriptions give users access to advanced features in exchange for a monthly fee. Verified badges, ad-free experience, and enhanced analytics are popular premium perks.

Advertising works well at scale. Sponsored posts and promoted content can generate significant revenue once you have consistent traffic, but it requires a sizable user base to be meaningful.
Marketplace commissions are powerful if your platform facilitates any kind of buying or selling. Taking a percentage on transactions adds up quickly.

Virtual gifts and in-app currency perform especially well on entertainment and creator-focused platforms where users want to show appreciation for content they love.

Start with one or two revenue streams and expand as you grow. Overcomplicating monetization too early creates friction for new users.

Common Mistakes to Avoid

A few pitfalls come up again and again in social platform development, and they're worth knowing about before you're in the middle of one.

Building too many features before launch is the most common error. Feature creep delays your timeline and burns your budget on things users may not even want. Launch lean and iterate based on real feedback.

Underestimating content moderation is another costly mistake. Without automated filters, reporting tools, and clear community guidelines, spam and low-quality content will overrun your platform fast.
Finally, don't try to be everything to everyone. The most successful social networks dominate a small, specific audience before they expand. Start narrow, build deep loyalty, then grow from there.

Final Thoughts

Building a social platform is genuinely exciting, and it's more accessible than most people think. You don't need a massive budget or a year-long timeline to get something real in front of users.

Social networking website development comes down to making smart decisions early: knowing your audience, choosing the right development approach, building the features that actually matter, and exploring technologies such as AI Agents for Social Media to improve engagement, content management, and user interactions. Get those foundations right and you've got a real shot at building something people keep coming back to. Start with a focused plan, stay close to your users, and don't wait for perfect before you ship.

I Had Never Touched a Mobile Core Network. Then I Shipped a PR to Magma's Production Codebase

Wed, 19 Aug 2026 06:26:42 +0000

A few weeks ago I had never touched a mobile core network. I didn't know what an EPC was, what AGW stood for, or why anyone would run a 4G stack on their laptop.

Today I've deployed one, fixed a production bug in it, and shipped a PR that's now part of the codebase. Here's how that happened.

What is Magma?

Magma is a Linux Foundation Networking project — an open-source mobile core network platform that lets you deploy 4G and 5G infrastructure without expensive proprietary hardware. Think of it as the software that sits between your phone and the internet when you're on a cellular network.

I joined as a mentee with basically zero telecom knowledge. What followed was one of the most intense technical learning experiences I've had.

Deploying the stack

The first challenge was just getting the thing running. Magma's Access Gateway (AGW) runs inside Docker containers, and the setup involves coordinating a lot of moving parts — orchestration, subscriber databases, the gateway itself. Getting through that process from scratch forced me to actually understand what each component does, not just follow steps.

Finding the Ubuntu 24.04 breakage

Once the environment was running, I started auditing the Dockerfiles. The project had accumulated dependencies that silently broke on newer Ubuntu:

python3-distutils — removed in Ubuntu 24.04, so installs fail quietly
libssl1.1 — not available on 24.04, replaced by libssl3

These aren't the kind of errors that scream at you. You have to actually check whether what the Dockerfile is requesting still exists in the target OS.

The fix: 14 files, one PR

The fix wasn't just swapping package names:

Updated the subscriberdb Dockerfile to use Ubuntu 24.04 as base
Replaced deprecated packages with their 24.04 equivalents
Updated the GitHub Actions CI workflow to test against a matrix of ubuntu-20.04 and ubuntu-24.04
Traced the breakage across 14 files where OS assumptions were baked in

The CI matrix means future contributors will catch OS-specific breakage before it ships — that felt meaningful. Not just fixing something, but making it harder to break again.

What surprised me

Open-source maintenance is a lot of archaeology. Code accumulates assumptions — about the OS, about which packages exist, about the Python version installed — and nobody documents them because at the time they were obvious. Finding them means reading carefully and asking what the code expects, not just what it does.

The second surprise: telecom infra sounds intimidating, but it's just software running in containers, with logs you can read like anything else.

What's next

I recently graduated from the Magma mentorship program (spring 2026 cohort) — credential here. Continuing to contribute to Magma while going deeper on the ML side — agentic AI frameworks, research papers, and projects connecting both worlds.

Originally posted on my blog — I write about ML, systems, and open source there.

I Had Never Touched a Mobile Core Network. Then I Shipped a PR to Magma's Production Codebase

Tue, 18 Aug 2026 17:07:16 +0000

A few weeks ago, I had never touched a mobile core network.

I didn't know what an EPC was. I didn't know what AGW stood for. And I definitely didn't understand why someone would want to run a 4G network stack on their laptop.

Then I joined the Magma mentorship program.

By the end of it, I had deployed a mobile core network locally, investigated a real compatibility problem, traced the issue across the codebase, updated the affected Dockerfiles and CI configuration, and shipped a pull request that became part of the project.

This is the story of how I went from knowing almost nothing about telecom infrastructure to contributing to a production open-source codebase.

What Is Magma?

Magma is an open-source mobile core network platform under the Linux Foundation Networking ecosystem.

At a high level, a mobile core sits behind the radio access network and handles things such as authentication, subscriber management, routing, and connectivity between mobile users and external networks.

Magma provides software components that allow organizations and developers to build and operate mobile networks using open-source technologies rather than relying entirely on proprietary infrastructure.

For someone coming from a computer science and AI background, it sounded intimidating.

I joined the Spring 2026 Magma mentorship cohort with essentially zero telecom experience.

That turned out to be a good thing.

Instead of trying to learn everything about telecommunications before touching the code, I learned by getting the system running and then following the problems wherever they led.

The First Challenge: Getting the Stack Running

My first goal wasn't to fix anything.

It was simply:

Get Magma running locally.

The Access Gateway (AGW) uses Docker containers, and getting the complete environment working involves multiple components communicating with each other.

There are services for things like:

The Access Gateway
Subscriber databases
Orchestration
Networking
Monitoring and supporting services

At first, this looked like a huge collection of unrelated components.

But getting the system running forced me to understand how they fit together.

That was probably one of the most valuable parts of the entire experience.

Instead of reading a definition of a mobile core network and memorizing it, I could actually see the software running.

I could inspect containers.

I could read logs.

I could follow dependencies.

And whenever something broke, I had a concrete problem to investigate.

From Running the System to Reading the Code

Once I had the environment working, I started looking through the project's Dockerfiles and build configuration.

That's where I found something interesting.

Some of the project's assumptions about the underlying Ubuntu environment were no longer valid on newer versions of Ubuntu.

The problems weren't necessarily obvious.

A Dockerfile might request a package that had existed for years.

That doesn't mean the package still exists in a newer Ubuntu release.

And that's where software maintenance becomes interesting.

The code may still look perfectly reasonable.

The assumption underneath it may simply be outdated.

Finding the Ubuntu 24.04 Breakage

Two examples immediately stood out.

`python3-distutils`

The project depended on python3-distutils, but distutils had been removed from newer Python/Ubuntu environments.

As a result, an installation that worked on an older environment could fail when the same assumptions were applied to Ubuntu 24.04.

`libssl1.1`

Another issue involved:

libssl1.1

Ubuntu 24.04 no longer provides that old OpenSSL package in the same way.

The newer environment uses the OpenSSL 3 series, including libssl3.

These aren't spectacular errors.

There isn't always a giant message saying:

"This Dockerfile is outdated."

Instead, you get an installation failure somewhere in the middle of a much larger build.

You have to ask:

What exactly is this Dockerfile assuming about the operating system?

That question led me much deeper into the codebase.

The Fix Wasn't Just Changing Two Package Names

At first glance, the solution looked simple.

Replace the old packages.

Build again.

Done.

It wasn't.

The same underlying assumptions appeared in multiple places.

I ended up tracing the issue across 14 files where Ubuntu versions, packages, or OS-specific assumptions were involved.

The changes included:

Updating the subscriberdb Dockerfile to use Ubuntu 24.04 as the base.
Replacing packages that were no longer available with their appropriate 24.04 equivalents.
Updating the GitHub Actions CI workflow.
Adding Ubuntu 24.04 alongside Ubuntu 20.04 in the testing matrix.
Checking the affected Dockerfiles for additional compatibility assumptions.

That last part was important.

Fixing the immediate error is one thing.

Making sure the same problem is less likely to happen again is another.

Why the CI Change Mattered

One of the changes I was particularly happy about was the CI matrix.

Instead of testing against only one Ubuntu environment, the workflow could test multiple versions:

ubuntu-20.04

and

ubuntu-24.04

This means an OS-specific compatibility issue has a better chance of being detected automatically.

That changes the contribution from:

"I fixed my environment."

to:

"I helped make the project more resilient to different environments."

That's a much more satisfying kind of open-source contribution.

What Open-Source Maintenance Actually Feels Like

Before this experience, I imagined contributing to a large open-source project mostly meant finding an issue, writing some code, and opening a pull request.

The reality was different.

A lot of maintenance is archaeology.

You encounter code written at a particular point in time.

At that time:

A particular package existed.
A particular Ubuntu version was common.
A particular Python version was installed.
A particular dependency behaved in a particular way.

Years later, those assumptions may no longer hold.

But the code still contains them.

Nobody necessarily wrote down why they were there because, when the code was originally written, the reason was obvious.

As a contributor, you have to reconstruct that history from the code, configuration files, documentation, build logs, and CI failures.

That was one of the biggest lessons I took away from the project.

Telecom Infrastructure Wasn't As Scary As It Sounded

The other thing that surprised me was how approachable the underlying debugging process became.

"Mobile core network" sounds like an enormous specialized field.

And it is.

There is a huge amount of telecommunications knowledge behind technologies such as LTE, EPC, 5G, authentication, subscriber management, and network interfaces.

But I didn't need to become a telecom expert before contributing.

The debugging process was still familiar.

Something doesn't work.

You check the logs.

You trace the dependency.

You inspect the configuration.

You reproduce the problem.

You look at the relevant code.

You make a small change.

You test it.

Then you discover that your "small change" actually affects five other things.

That's software engineering.

The domain was unfamiliar.

The debugging mindset wasn't.

From Beginner to Contributor

The most valuable part of the experience wasn't the specific Ubuntu fix.

It was realizing that you don't need to understand an entire codebase before you can contribute to it.

You need a sufficiently small problem to start with.

My starting point was essentially:

"Why isn't this environment building correctly?"

That question eventually led me through Docker, Ubuntu packages, CI workflows, networking infrastructure, and parts of the Magma architecture.

I learned the domain because I needed the knowledge to solve the problem.

That was much more effective for me than trying to learn telecommunications completely in isolation.

What I Learned

If I had to summarize the experience into a few lessons, they would be these.

1. Don't be afraid of unfamiliar codebases

A repository can look enormous.

You don't need to understand all of it.

Find one small problem and follow it.

2. Read the assumptions, not just the code

A Dockerfile isn't just a list of commands.

It contains assumptions about the operating system, packages, architecture, and runtime environment.

Those assumptions are often where compatibility problems hide.

3. Reproducing a problem is already progress

Before fixing something, I needed to understand exactly what was failing.

Being able to reproduce a problem turns a vague bug into something concrete.

4. A good fix prevents future problems

Changing one package name might solve today's build.

Adding compatibility testing can help prevent tomorrow's regression.

5. Open source is one of the best ways to learn systems

You get to work with software that other people actually depend on.

The feedback loop is completely different from building another isolated tutorial project.

Someone else reviews your changes.

CI tests them.

Maintainers question your assumptions.

And suddenly the code you wrote has to survive outside your laptop.

What's Next?

I recently graduated from the Spring 2026 Magma mentorship program, and I'm continuing to explore open-source systems work.

At the same time, I'm going deeper into machine learning, agentic AI frameworks, research papers, and projects that connect AI with systems and real-world software.

The Magma experience reinforced something I want to keep doing:

Go into areas I don't fully understand, find difficult problems, and learn by building.

A few weeks before this project, I didn't know what an AGW was.

I certainly didn't expect my first serious telecom contribution to involve tracking Ubuntu package compatibility across 14 files.

But that's exactly what made the experience worth it.

Sometimes the best way to learn a new field isn't to wait until you're ready.

It's to find a problem that's slightly beyond your current understanding—and start digging.

Originally published on my DEV Community and personal blog.

DNS Records Explained: A, AAAA, CNAME, MX, TXT, NS, and SRV Records in Modern Internet Infrastructur

Mon, 10 Aug 2026 16:35:02 +0000

In the previous article, we explored how DNS translates human-friendly domain names into machine-friendly IP addresses and how a request travels through recursive resolvers, root servers, TLD servers, and authoritative nameservers before finally reaching a destination.

That journey answers how DNS works.

This article answers a different question:

What information is DNS actually returning?

When a DNS resolver contacts an authoritative nameserver, it isn’t simply asking for an IP address.

It is asking for a specific record.

Those records determine:

Where websites live
Where email should be delivered
Which servers are authoritative
How domains are verified
How email is authenticated
How cloud services are discovered
How SaaS platforms connect custom domains
How modern internet infrastructure operates

In other words:

DNS resolution is the process.

DNS records are the data.

Understanding DNS records is where DNS knowledge becomes practical.

Whether you’re launching a website, migrating infrastructure, configuring email, deploying applications, implementing custom domains, or troubleshooting production systems, DNS records sit at the center of the operation.

Why DNS Records Matter More Than Most People Realize

Many internet outages aren’t caused by application bugs.

They aren’t caused by database failures.

They aren’t caused by cloud providers.

They’re caused by configuration mistakes.

A misplaced DNS record can:

Take an entire website offline
Stop customer emails from arriving
Break API connectivity
Prevent SSL certificate issuance
Disrupt SaaS onboarding
Cause search engines to lose access to content

The irony is that DNS records are often configured once and forgotten until something breaks.

That’s why understanding them matters.

DNS Records: The Source of Truth Behind Every Domain

Imagine someone enters:

code

example.com

into a browser.

Eventually the request reaches the authoritative nameserver.

The authoritative nameserver responds with records stored inside its DNS zone.

Example:

code

example.com. IN A 203.0.113.10

The response tells the internet:

code

example.com
       ↓
203.0.113.10

That single record determines where traffic goes.

Without DNS records, DNS itself would be useless.

Understanding DNS Record Types

Modern DNS contains dozens of record types.

However, seven records power the overwhelming majority of websites, applications, email systems, and cloud services.

Record TypePrimary PurposeAMaps hostname to IPv4AAAAMaps hostname to IPv6CNAMECreates aliasesMXRoutes emailTXTVerification and securityNSDefines authoritative nameserversSRVService discovery

These records form the foundation of modern internet infrastructure.

A Record Explained

The A Record is the most fundamental DNS record.

The “A” stands for:

Address

It maps a hostname directly to an IPv4 address.

Example:

code

example.com. IN A 203.0.113.10

This creates a direct relationship:

code

example.com
       ↓
203.0.113.10

When someone visits the domain, traffic is sent to that server.

Why A Records Are So Important

Every website needs a destination.

The A Record provides that destination.

Without it:

Browsers cannot locate servers
Applications cannot connect
APIs become unreachable

Even the most advanced infrastructure eventually depends on records that resolve to an IP address.

Where A Records Are Commonly Used

Typical examples include:

code

company.com
portfolio.com
store.com
api.company.com
app.company.com

Almost every publicly accessible website uses A records somewhere in its architecture.

Production Reality: A Record Migrations

One of the most common infrastructure projects involves moving applications between servers.

For example:

code

Old Server
203.0.113.10

becomes:

code

New Server
203.0.113.50

Updating the A Record redirects traffic globally without requiring users to change anything.

This simple capability is one reason DNS remains such a powerful abstraction layer.

AAAA Record Explained

The AAAA Record performs the same role as an A Record.

The difference is the addressing standard.

RecordProtocolAIPv4AAAAIPv6

Example:

code

example.com. IN AAAA 2001:db8::1

Why IPv6 Exists

IPv4 provides approximately:

code

4.3 Billion Addresses

That seemed enormous in the early days of the internet.

Today, it isn’t.

Cloud computing, smartphones, IoT devices, smart vehicles, and connected infrastructure accelerated address consumption dramatically.

IPv6 was created to solve that limitation.

Should Every Website Use AAAA Records?

Not necessarily.

A common mistake is enabling IPv6 before infrastructure is ready.

If an application doesn’t properly support IPv6, users may experience connectivity problems despite having perfectly functioning IPv4 infrastructure.

IPv6 should be enabled deliberately rather than automatically.

CNAME Record Explained

CNAME stands for:

Canonical Name

Unlike an A Record, a CNAME does not point to an IP address.

Instead, it points to another hostname.

Example:

code

www.example.com IN CNAME example.com

Which effectively means:

code

www.example.com
         ↓
example.com
         ↓
203.0.113.10

Why CNAME Records Exist

Imagine managing:

code

www.example.com
blog.example.com
docs.example.com
shop.example.com

If each hostname pointed directly to an IP address, every infrastructure change would require updating multiple records.

CNAME records eliminate that complexity.

One change updates every dependent hostname.

Why Modern SaaS Platforms Love CNAME Records

Custom domains have become a standard expectation.

Instead of:

code

customer.platform.com

many organizations prefer:

code

app.customer-domain.com

The most common implementation relies on CNAME records.

This approach allows millions of customer domains to connect to shared infrastructure while maintaining branding and flexibility.

The Hidden Complexity of Custom Domains

What appears simple on the surface often requires:

Domain ownership verification
DNS validation
SSL certificate provisioning
Traffic routing
Edge network configuration

Behind a single CNAME record is often a surprisingly sophisticated platform architecture.

CNAME vs A Record

One of the most common questions is:

When should an A Record be used?

When pointing directly to an IP address.

Example:

code

example.com IN A 203.0.113.10

When should a CNAME be used?

When pointing to another hostname.

Example:

code

www.example.com IN CNAME example.com

Simple Rule

Use:

code

A Record

for servers.

Use:

code

CNAME

for aliases.

MX Record Explained

MX stands for:

Mail Exchange

MX records tell the internet where incoming email should be delivered.

Example:

code

example.com IN MX 10 mail.example.com

Without MX records:

Email cannot function.

Why MX Records Matter More Than Most Websites

A website outage is visible.

An email outage often isn’t.

Messages simply disappear.

Leads go unanswered.

Support requests never arrive.

Invoices are missed.

Customers assume silence means neglect.

The business impact can be substantial.

Understanding MX Priority

Example:

code

MX 10 mail-primary.example.com
MX 20 mail-backup.example.com

Lower values receive priority.

If the primary server becomes unavailable, mail automatically flows to the backup system.

This redundancy improves reliability.

TXT Record Explained

TXT records are among the most flexible records in DNS.

Historically they stored simple text.

Today they support critical infrastructure functions.

TXT Records Power Modern Trust Systems

Many internet services rely on TXT records to verify ownership.

Examples include:

Google Search Console
Microsoft 365
Cloud platforms
Email providers
SSL certificate services

Example:

code

google-site-verification=abc123

This proves domain ownership without requiring direct server access.

TXT Records and Email Security

TXT records are heavily used by:

SPF

Defines authorized email senders.

code

v=spf1 include:_spf.google.com ~all

DKIM

Provides cryptographic email signatures.

DMARC

Defines authentication policies.

Together these technologies help reduce:

Email spoofing
Phishing
Domain impersonation

In modern environments, email security is largely a DNS problem before it becomes an email problem.

NS Record Explained

NS stands for:

Name Server

NS records define which nameservers hold authority over a domain.

Example:

code

example.com IN NS ns1.cloudflare.com
example.com IN NS ns2.cloudflare.com

These records tell the internet:

These servers contain the source of truth.

Why NS Records Matter

Without NS records, the DNS hierarchy breaks.

Resolvers would have no way of discovering where authoritative information lives.

Every lookup ultimately depends on NS records.

They form the bridge between domain ownership and DNS management.

A Real Infrastructure Example

A domain may be registered through one provider.

DNS may be hosted elsewhere.

For example:

code

Registrar:
Namecheap

DNS Provider:
Cloudflare

NS records connect those two systems.

SRV Record Explained

SRV stands for:

Service Record

SRV records provide more information than a simple address.

They specify:

Service
Protocol
Port
Priority
Weight

Example:

code

_sip._tcp.example.com

Why SRV Records Exist

Many applications need more than an IP address.

Examples include:

SIP systems
VoIP platforms
Active Directory
Enterprise applications
Gaming infrastructure

SRV records allow applications to discover services automatically.

This reduces manual configuration and improves scalability.

DNS Records Every Modern Website Typically Uses

A standard production setup often includes:

Website Access

code

A Record
CNAME Record

Email Infrastructure

code

MX Record
SPF
DKIM
DMARC

Security and Verification

code

TXT Record

DNS Authority

code

NS Record

DNS Records During Website Migrations

Website migrations often fail because DNS planning is treated as an afterthought.

Common mistakes include:

Forgetting MX records
Removing TXT records
Incorrect TTL settings
Deleting verification records
Breaking email authentication

Successful migrations involve auditing DNS before moving infrastructure.

DNS Records and Search Visibility

DNS records do not directly improve rankings.

However, they influence systems that do.

Reliable DNS supports:

Website availability
Search engine accessibility
Email trust
User experience
Infrastructure reliability

Poor DNS management can undermine otherwise excellent websites.

Quick Reference Table

GoalRecord TypeHost a WebsiteAEnable IPv6AAAACreate an AliasCNAMEReceive EmailMXVerify Domain OwnershipTXTConfigure SPFTXTConfigure DKIMTXTConfigure DMARCTXTDelegate DNS AuthorityNSDiscover ServicesSRV

Key Takeaways

DNS records are the data layer of DNS.
A Records connect hostnames to IPv4 addresses.
AAAA Records connect hostnames to IPv6 addresses.
CNAME Records create aliases.
MX Records control email routing.
TXT Records power verification and security.
NS Records define authoritative nameservers.
SRV Records support service discovery.
Modern websites, cloud platforms, SaaS applications, and email systems depend on DNS records.
Understanding DNS records helps prevent outages, improve reliability, and simplify infrastructure management.

DNS Explained: The Complete Guide for Founders, Developers, and Modern Businesses

Sat, 08 Aug 2026 17:06:27 +0000

Most people don’t think about DNS until something breaks.

A founder launches a new website and suddenly email stops working.

A developer migrates infrastructure and traffic starts disappearing.

A marketing team changes a domain setting and the website becomes unreachable.

A SaaS company adds custom domains and discovers that domain management is far more complicated than expected.

The reality is simple:

DNS is one of the most critical systems on the internet, yet it’s one of the least understood.

Every website, API, SaaS platform, email service, mobile application, cloud platform, and online business depends on DNS.

Google depends on DNS.

Cloudflare depends on DNS.

AWS depends on DNS.

Your startup depends on DNS.

And while DNS often appears simple from the outside, there is an incredible amount of engineering hidden beneath a single domain lookup.

This article is designed for both founders and developers.

If you’re a founder, you’ll understand how DNS impacts business continuity, SEO, security, email delivery, and customer experience.

If you’re a developer, you’ll understand how DNS resolution actually works, why DNS records matter, how cloud platforms use DNS internally, and how production-grade systems are built around it.

Let’s start at the beginning.

What Is DNS?

DNS stands for:

Domain Name System

The easiest explanation is:

DNS translates human-friendly names into machine-friendly addresses.

Humans prefer:

code

openai.com

Computers prefer:

code

104.18.33.45

DNS acts as the translation layer between those two worlds.

Without DNS, every website visit would require memorizing numerical IP addresses.

Instead of typing:

code

google.com

you would need to type something similar to:

code

142.250.190.78

for every website you wanted to visit.

Clearly, that wouldn’t scale.

DNS solves this problem by creating a globally distributed naming system.

DNS Is the Internet’s Directory Service

Imagine the internet as a massive city.

Every building has a street address.

Computers only understand addresses.

Humans prefer names.

DNS functions like a directory service that translates:

code

Company Name
        ↓
Street Address

code

Domain Name
        ↓
IP Address

The idea sounds simple.

The engineering required to make this work globally, reliably, and within milliseconds is not.

Why Founders Should Care About DNS

Many founders think DNS is purely a technical concern.

That’s a mistake.

DNS directly affects:

Website Availability

If DNS fails:

Your website disappears.

Not slow.

Not degraded.

Gone.

Users can’t reach it.

Search engines can’t crawl it.

Customers can’t buy from it.

Email Delivery

Many businesses discover DNS only after email breaks.

DNS controls:

Google Workspace
Microsoft 365
Zoho Mail
Custom email servers

A single DNS mistake can prevent:

Sales emails
Customer support
Password resets
Transactional notifications

from reaching users.

SEO Performance

DNS impacts:

Availability
Website speed
Crawlability
User experience

Search engines cannot rank websites they cannot consistently access.

Brand Trust

Imagine a customer visiting:

code

yourbusiness.com

and seeing:

code

This site can't be reached

Trust disappears instantly.

DNS is part of your brand infrastructure.

Why Developers Must Understand DNS

Modern development isn’t just writing code.

Today developers manage:

APIs
Cloud infrastructure
Containers
Load balancers
SSL certificates
SaaS platforms
Multi-region deployments

DNS sits in the middle of all of them.

A surprising number of production incidents ultimately trace back to DNS.

Understanding DNS turns infrastructure troubleshooting from guesswork into engineering.

The DNS Resolution Process

When a user enters:

code

www.example.com

inside a browser, what actually happens?

Most people imagine:

code

Browser
    ↓
Website

Reality is significantly more complex.

Step 1: Browser Cache

The browser first asks:

Have I looked up this domain recently?

If yes:

The browser already knows the answer.

No external DNS request is needed.

The website loads immediately.

This is called DNS caching.

Step 2: Operating System Cache

If the browser doesn’t know the answer, it asks the operating system.

Windows, Linux, macOS, Android, and iOS maintain DNS caches.

Again:

If the answer exists locally, the process ends here.

Step 3: Recursive Resolver

If no cached answer exists, the request reaches a recursive DNS resolver.

Examples include:

Cloudflare DNS:

code

1.1.1.1

Google DNS:

code

8.8.8.8

Your ISP’s DNS servers.

The resolver’s job is:

Find the answer on behalf of the user.

Step 4: Root Nameservers

The resolver begins at the top of the DNS hierarchy.

The internet contains root DNS servers.

These servers don’t know the IP address of every website.

Instead they know:

Which servers are responsible for top-level domains.

For example:

code

.com
.org
.net
.io
.dev

Step 5: Top-Level Domain Servers

Suppose you’re looking for:

code

example.com

The root server responds:

Ask the .com nameservers.

The resolver now contacts the .com infrastructure.

Step 6: Authoritative Nameservers

The .com servers respond:

The authoritative DNS servers for example.com are located here.

Now the resolver knows exactly where to find the truth.

Step 7: Final Answer

The authoritative DNS server returns:

code

203.0.113.10

The resolver caches the answer.

The browser receives the answer.

The website loads.

All of this often happens in less than 100 milliseconds.

The DNS Hierarchy

DNS is not a giant database.

It’s a distributed hierarchy.

Think of it as:

code

Root
 ├── .com
 ├── .org
 ├── .net
 ├── .io
 └── .dev

Under each TLD:

code

example.com
openai.com
github.com

Under each domain:

code

www.example.com
api.example.com
mail.example.com

This hierarchical design is one reason DNS scales globally.

Understanding DNS Records

DNS records are instructions.

Different record types solve different problems.

Understanding them is essential for production systems.

A Record

Maps a hostname to an IPv4 address.

Example:

code

example.com. IN A 203.0.113.10

This is the most common DNS record.

AAAA Record

Maps a hostname to an IPv6 address.

Example:

code

example.com. IN AAAA 2001:db8::1

IPv6 adoption continues growing across cloud providers and ISPs.

CNAME Record

Creates an alias.

Example:

code

www.example.com IN CNAME example.com

Useful when multiple hostnames point to the same service.

MX Record

Controls email routing.

Example:

code

example.com IN MX 10 mail.example.com

Without MX records:

Email fails.

TXT Records

One of the most versatile DNS record types.

Used for:

Domain verification
SPF
DKIM
DMARC
Third-party integrations

Founders often encounter TXT records when connecting:

Google Workspace
Microsoft 365
Search Console
Cloud providers

NS Records

NS records define authoritative nameservers.

Example:

code

example.com IN NS ns1.provider.com
example.com IN NS ns2.provider.com

These servers become responsible for your DNS zone.

Why DNS Propagation Takes Time

One of the most common questions:

Why isn’t my DNS change working?

Usually because of caching.

Understanding TTL

TTL means:

Time To Live

Example:

code

TTL = 3600

This means:

code

Cache for 1 hour

Resolvers keep answers cached until TTL expires.

The Truth About DNS Propagation

DNS doesn’t actually “spread” changes.

Resolvers simply stop trusting cached data and ask again.

This process creates the appearance of propagation.

Understanding this distinction helps developers troubleshoot DNS issues more effectively.

DNS and Website Performance

DNS is the first network request most users make.

Before:

HTML
CSS
JavaScript
APIs

DNS must succeed.

Slow DNS creates slower websites.

Measuring DNS Performance

Common metrics include:

DNS lookup time
TTFB
Latency
Availability

A slow DNS provider adds measurable delays before page rendering begins.

DNS and SEO

Many SEO guides barely discuss DNS.

That’s unfortunate because DNS indirectly impacts search performance.

Availability Matters

Search engines need consistent access.

If DNS failures occur:

Crawling suffers
Indexing suffers
Rankings may suffer

Performance Matters

Google increasingly rewards user experience.

Fast DNS contributes to:

Faster page loads
Better engagement
Improved performance metrics

Reliability Matters

Enterprise-grade DNS infrastructure improves uptime.

Uptime improves trust.

Trust improves long-term search visibility.

DNS and GEO (Generative Engine Optimization)

A new challenge is emerging.

Users increasingly discover businesses through AI systems.

Large language models, AI search engines, and answer engines rely heavily on accessible infrastructure.

Reliable DNS contributes to:

Consistent crawling
Better accessibility
Reliable content retrieval

As GEO evolves, infrastructure quality becomes increasingly important.

DNS Security Explained

DNS is also a major attack surface.

DNS Spoofing

Attackers attempt to redirect users toward malicious destinations.

The victim enters:

code

bank.com

but reaches:

code

attacker-site.com

without realizing it.

DNS Cache Poisoning

Attackers inject false DNS responses into caches.

Users receive incorrect answers.

This can lead to phishing and credential theft.

DNSSEC

DNSSEC adds cryptographic signatures.

Benefits include:

Authenticity
Integrity
Protection against spoofing

DNSSEC doesn’t encrypt DNS.

It verifies DNS.

That’s an important distinction.

Email Authentication and DNS

Email security relies heavily on DNS.

Three records are especially important.

SPF

Defines which servers can send email.

DKIM

Provides cryptographic email signatures.

DMARC

Defines enforcement policies.

Together they reduce:

Spoofing
Phishing
Email fraud

How Cloud Providers Use DNS

Cloud infrastructure relies heavily on DNS.

AWS.

Azure.

Google Cloud.

Cloudflare.

DigitalOcean.

All use DNS extensively.

Load Balancing

DNS can distribute traffic.

Example:

code

app.example.com

might resolve to multiple servers.

Benefits:

Scalability
Redundancy
Reliability

Geographic Routing

Users in Singapore may reach Asian infrastructure.

Users in Germany may reach European infrastructure.

Users in New York may reach US infrastructure.

DNS can make these routing decisions automatically.

DNS for SaaS Applications

This is where things become particularly interesting.

Suppose you’re building a SaaS platform.

Your customers want:

code

client-company.com

instead of:

code

client.yourapp.com

This requires custom domain support.

Custom domain support requires DNS verification.

DNS verification requires ownership validation.

DNS becomes part of your product architecture.

Many SaaS founders underestimate this complexity.

Common DNS Mistakes in Production

Over the years, the same mistakes appear repeatedly.

Deleting Records Accidentally

Migration projects frequently break email because MX records were forgotten.

Ignoring TTL

Developers make changes expecting instant results.

DNS doesn’t work that way.

No DNS Monitoring

Businesses discover outages from customers instead of monitoring systems.

No Redundancy

Single-provider DNS creates unnecessary risk.

Missing Email Security Records

SPF, DKIM, and DMARC are often ignored until deliverability problems appear.

Practical DNS Tools Every Developer Should Know

dig

code

dig example.com

The gold standard for DNS troubleshooting.

nslookup

code

nslookup example.com

Widely available across operating systems.

host

code

host example.com

Quick and simple DNS lookups.

whois

code

whois example.com

Useful for domain ownership and registration information.

Key Takeaways

DNS is the internet’s naming system.
Every website, API, email service, and cloud platform relies on DNS.
DNS translates domain names into IP addresses.
DNS is hierarchical and globally distributed.
DNS records control websites, email, security, and service routing.
DNS impacts performance, reliability, SEO, and user experience.
DNSSEC improves DNS trust and authenticity.
SaaS applications often depend heavily on DNS architecture.
Understanding DNS is valuable for founders and essential for developers.

Final Thoughts

The best infrastructure is often invisible.

Users never think about DNS when everything works.

Yet every successful online business depends on it.

Founders view DNS as a domain setting.

Developers eventually realize it’s a foundational internet protocol.

The deeper you go into cloud architecture, distributed systems, SaaS platforms, cybersecurity, and modern software engineering, the more often you’ll encounter DNS.

Understanding DNS isn’t just about configuring records.

It’s about understanding how the internet itself finds, trusts, and connects systems together.

And once you understand that, you’ll start seeing DNS everywhere.

Cloud-Based Network Monitoring: How It Works, Key Metrics, and Best Practices

Thu, 06 Aug 2026 15:01:53 +0000

Cloud-based network monitoring enables organizations to monitor, manage, and optimize their network infrastructure remotely through cloud-hosted platforms. It provides real-time visibility into network performance, device health, traffic patterns, and security events, allowing IT teams to quickly identify and resolve issues before they impact business operations. Compared to traditional on-premises monitoring, cloud-based solutions offer greater scalability, flexibility, centralized management, and reduced infrastructure costs, making them well suited for modern hybrid and distributed environments.

Successful cloud-based network monitoring depends on selecting the right monitoring platform, maintaining comprehensive visibility across cloud and on-premises resources, configuring real-time alerts, and continuously analyzing performance data. By adopting proactive monitoring practices, organizations can improve network reliability, strengthen security, optimize resource utilization, and ensure consistent performance as their infrastructure grows and evolves.

Source: This summary is based on the blog "Cloud-Based Network Monitoring" by PathSolutions.

Blog URL: https://www.pathsolutions.com/blog/cloud-based-network-monitoring

Airtel 5G ODU vs MTN 5G ODU: My Honest Experience After Weeks of Testing in Nigeria

Wed, 05 Aug 2026 09:57:21 +0000

Airtel 5G ODU vs MTN 5G ODU: My Honest Experience After Weeks of Testing in Nigeria

The arrival of 5G Fixed Wireless Access (FWA) in Nigeria promised something many Nigerians have waited years for—fiber-like internet without laying cables. Airtel and MTN both launched their Outdoor Units (ODUs), promising fast, reliable internet for homes and businesses.

On paper, both products look impressive.

In reality, your experience depends almost entirely on one thing:

Is there actually a 5G tower serving your location?

After spending time with the Airtel 5G ODU, analyzing signal information, checking neighboring cell towers, comparing coverage maps, and monitoring speed tests across different times of the day, here's what I found.

First Things First: A 5G Router Doesn't Mean You'll Get 5G

This is probably the biggest misconception.

Many people assume:

Buy a 5G router = Get 5G internet.

Unfortunately, that's not how mobile networks work.

A 5G router can only connect to a 5G cell if:

there is a nearby 5G tower,
the tower has available capacity,
your signal quality is good enough,
and the operator has actually deployed 5G in your area.

Otherwise...

The router simply falls back to LTE (4G/4G+).

That is exactly what happened in my case.

My Experience with the Airtel 5G ODU

I live in a very popular part of Port Harcourt.

Based on how developed the area is, I naturally assumed Airtel would already have 5G coverage.

So I purchased the Airtel 5G ODU because I urgently needed better internet for work.

From the very first day...

I have never connected to Airtel 5G.

Not once.

Even after forcing the router to:

5G (NSA)
Automatic 5G

It still connects as:

4G+

Every single time.

Looking Deeper into the Router

After checking the engineering statistics inside the router, several things became obvious.

The router reports:

RSRP around -72 dBm
RSRQ around -4 dB
SINR around 12 dB

These are actually respectable LTE signal values.

The router also reports only 4G neighboring cells, while the 5G neighboring cell list remains empty, indicating that no usable Airtel 5G cell is available at the installation point.

The router is healthy.

The signal is healthy.

The missing piece is simply:

No Airtel 5G cell to connect to.

That means the router is behaving exactly like a premium 4G router.

The Marketing Problem

This is where I believe expectations and reality differ.

The device is heavily marketed as a 5G router.

Technically, that statement is correct.

But many buyers interpret it as:

"Buy this router and you'll enjoy 5G."

That is not guaranteed.

If Airtel has not deployed 5G where you live, then what you've purchased is effectively an expensive LTE router.

That doesn't necessarily make the product bad.

It just means coverage matters far more than the hardware.

The eSIM Surprise

One interesting discovery was that the ODU internally uses an embedded SIM (eSIM) to communicate with Airtel's network.

However, after opening the device and inspecting it carefully, it also appears capable of accepting a physical SIM card from the supported operator.

Testing with a physical SIM produced essentially the same result.

The limitation wasn't the SIM.

It was simply the lack of an available Airtel 5G signal.

Real World Performance

This is where things became frustrating.

During quiet periods of the day:

browsing is fine
YouTube works
video calls are usable
normal office work is okay

Once daytime traffic increases...

everything changes.

Uploading documents becomes noticeably slower.

Cloud backups take much longer.

Large software downloads become inconsistent.

Remote desktop sessions start feeling sluggish.

If your work depends heavily on the internet software development, cloud infrastructure, media uploads, or large file transfers you'll quickly notice the limitations.

The network isn't unusable.

It's just not delivering what most people expect from a product carrying the "5G" label.

Then I Compared It with MTN

This is where things became interesting.

Using the official coverage maps from both operators, one thing becomes immediately noticeable.

MTN's 5G footprint appears significantly broader across many urban locations than Airtel's.

In several cities including parts of Port Harcourt MTN has deployed more visible 5G coverage than Airtel.

That doesn't mean MTN has perfect coverage.

It simply means your chances of actually connecting to 5G are generally higher.

If your location falls within MTN's active 5G coverage, the experience is much closer to what people expect from fixed wireless broadband.

Users typically report:

higher download speeds
lower latency
better upload performance
more consistent remote work experience

Night time performance is usually even better because fewer users are competing for bandwidth.

Why Time of Day Matters

One thing many reviews fail to mention is network congestion.

Mobile towers have finite capacity.

At around:

8 AM
lunchtime
evening
weekends

everyone is online.

People are:

watching YouTube
attending meetings
gaming
downloading updates
streaming Netflix
using TikTok

Everyone is competing for the same radio resources.

This explains why a speed test at 2 AM can look incredible while the exact same location performs much worse at 2 PM.

When reviewing any mobile broadband service, always ask:

What time was the speed test performed?

Without that context, speed tests can be misleading.

Mounting the ODU Correctly

Most people install these devices on a wall because it's easy.

Personally, I think that's leaving performance on the table.

Since these outdoor units rely on omnidirectional antennas to receive radio signals, they perform best when they have the clearest possible line of sight to nearby towers.

A better installation would be similar to how people install:

GOtv antennas
StarTimes antennas
TV aerials

Mounting the ODU higher on a pole or mast can reduce obstructions from buildings and trees and often improves signal quality.

Even small improvements in RSRP and SINR can translate into noticeably better throughput.

Before Buying Any 5G ODU

Don't buy based on advertising alone.

Instead, ask these questions first:

Does my area actually have 5G coverage?
Which operator has deployed more towers nearby?
Can someone nearby confirm they're getting a genuine 5G connection?
What are the speeds during peak hours not just at midnight?
Is the router connecting to NR (5G), or is it staying on LTE?

Doing this homework can save you a lot of disappointment.

My Verdict

The Airtel 5G ODU isn't a bad device.

In fact, the hardware appears capable.

The problem is that hardware alone cannot create a 5G connection.

Without sufficient Airtel 5G deployment in your location, the router behaves much like a high-end 4G+ router. That was my experience in Port Harcourt, and the signal information from the router supported that conclusion.

MTN currently seems to have a stronger 5G rollout in many urban areas, giving its ODU a better chance of delivering the performance buyers expect. However, this doesn't mean MTN will outperform Airtel everywhere coverage varies by neighborhood, and the only reliable predictor is the availability of a nearby 5G cell.

My advice is simple:

Don't buy a 5G router because it says "5G" on the box. Buy it because your location actually has usable 5G coverage.

A few minutes spent checking the official coverage maps and talking to people who already use the service in your neighborhood can save you money, frustration, and unrealistic expectations.

If you're fortunate enough to be within a well-served 5G area, these ODUs can be an excellent alternative to fiber. If not, you're likely paying a premium for what will effectively be a 4G+ experience until more 5G sites are deployed.

The Invisible Journey: Tracing Packets Through the Linux Kernel with eBPF and `pwru`

Sun, 26 Jul 2026 04:00:42 +0000

The modern developer's landscape is a complex tapestry of microservices, containers, and cloud infrastructure. When an application slows down, or a connection drops, the immediate culprits are often assumed to be the application code itself or the external network. But what about the invisible journey a packet takes inside the operating system? That often-opaque realm, the Linux kernel, holds the true story of network performance, packet drops, and elusive latency spikes.

For many developers, the kernel remains a mysterious black box. We interact with it daily through syscalls and network interfaces, but rarely peer into its inner workings. Traditional tools like tcpdump and netstat offer glimpses – what leaves our machine, what arrives, and what ports are open – but they often fall short when we need to understand why a packet was dropped, where it spent its time, or how it was processed before it ever reached the application. This is the gap that kernel-level observability tools, powered by eBPF, are rapidly filling.

Inspired by the journey of a fellow developer learning to navigate the kernel's network stack, this article aims to demystify the process of tracking a packet. We'll explore why deep kernel insight is crucial for modern debugging, introduce the revolutionary technology of eBPF, and then dive hands-on into pwru – an eBPF-based tool that makes the invisible journey of a packet through the Linux kernel visible and understandable. You don't need to be a kernel developer to unlock these insights; you just need the right tools and a guide to interpret their output.

The Invisible Journey: Why Deep Packet Tracing Matters

Imagine a web request taking too long. Your application logs show the request was received, but the response was delayed. Is it the database? The application logic? Or something happening deep within the network stack of your server, or even the client? Without kernel-level visibility, you're often left guessing.

Beyond the Wire: The Limitations of Userspace Tools

Tools like tcpdump are invaluable. They capture packets as they hit or leave a network interface, showing you what's on the wire. netstat or ss show you active connections, listening ports, and basic statistics. These are the frontline tools for network debugging, and they serve a critical purpose.

However, they have inherent limitations when you need to understand the internal processing of a packet:

Black Box Kernel: tcpdump sees packets before the kernel processes them on ingress and after the kernel has finished processing them on egress. What happens in between – routing decisions, firewall rules, socket buffer management, TCP stack processing – remains a mystery.
Packet Drops: If tcpdump doesn't show a packet leaving your machine, you know it never made it to the wire. But why? Was it dropped by a firewall? A full transmit queue? A routing error? tcpdump can't tell you the precise point of failure within the kernel.
Latency Attribution: A high round-trip time could be due to network latency, but it could also be due to significant processing delays within the kernel's network stack or the application's inability to read from the socket quickly enough. Isolating these factors is hard with userspace tools alone.
Context: Userspace tools often lack the rich context available inside the kernel, such as the specific kernel function being executed, the CPU core involved, or the network namespace.

Common Scenarios Demanding Kernel-Level Insight

Developers frequently encounter scenarios where kernel-level packet tracing becomes indispensable:

Mysterious Packet Drops: "My service isn't receiving all the packets it expects, but tcpdump on the interface shows them arriving." This suggests an internal kernel drop.
Unexplained Latency: "My application is slow, but CPU and memory usage are fine, and network latency to other services seems normal." Could it be contention within the kernel's network buffers or inefficient processing?
Firewall Troubleshooting: "I've configured iptables, but traffic still isn't flowing as expected, or is being unexpectedly blocked." Pinpointing the exact netfilter hook where a packet is dropped or modified is crucial.
Routing and Forwarding Issues: "Why isn't this packet being forwarded to the correct destination, even though my routing table looks correct?" Tracing the packet's path through the routing decision points can reveal the answer.
Complex Network Stacks: In environments using technologies like IPVS, BPF-based load balancers, or advanced container networking (e.g., Cilium, Calico), understanding the kernel's internal packet flow becomes paramount.

These challenges highlight the need for a deeper level of observability – one that allows us to peek inside the kernel and follow a packet's every step.

Enter eBPF: Programmable Kernel Observability

For decades, getting insight into the Linux kernel involved recompiling it, using ftrace, or relying on limited procfs entries. These methods were often cumbersome, risky, or lacked the necessary detail. The advent of eBPF (extended Berkeley Packet Filter) changed everything.

What is eBPF? (A High-Level Overview)

At its core, eBPF is a revolutionary technology that allows programs to run safely within the Linux kernel. Think of it as a highly efficient, event-driven virtual machine embedded directly in the kernel. Unlike traditional kernel modules, eBPF programs are:

Safe: All eBPF programs must pass a rigorous kernel verifier before execution, ensuring they don't crash the kernel, loop indefinitely, or access unauthorized memory.
Event-Driven: eBPF programs are attached to various "hook points" within the kernel. These can be:
- Kprobes/Kretprobes: Attach to the entry or exit of almost any kernel function.
- Uprobes/Uretprobes: Attach to the entry or exit of userspace functions.
- Tracepoints: Stable, well-defined points intentionally added by kernel developers for tracing.
- Network Hooks: For filtering and processing network packets.
- Syscall Hooks: Intercepting system calls.
Efficient: They execute in-kernel, avoiding costly context switches between userspace and kernel space. They are typically JIT-compiled to native machine code for maximum performance.
Programmable: Developers write eBPF programs (often in C, then compiled to eBPF bytecode using clang and llvm) to perform specific tasks: filter events, collect statistics, modify data, or redirect packets. These programs can then communicate results back to userspace via shared maps or ring buffers.

In essence, eBPF provides a powerful, flexible, and safe way to extend kernel functionality and gain unprecedented visibility into its operations without modifying kernel source code or rebooting.

The Power of eBPF for Networking

eBPF's origins are deeply rooted in networking (the original BPF was for packet filtering). Today, its capabilities for network observability and control are immense:

Advanced Packet Filtering: Beyond what iptables can do, eBPF programs can filter packets based on arbitrary criteria, even deep into application-layer protocols.
Traffic Control: Shaping, policing, and load balancing traffic directly in the kernel.
Security: Implementing fine-grained network policies and intrusion detection.
Observability: This is where pwru shines. By attaching eBPF programs to key network functions and tracepoints, we can collect detailed information about every packet as it traverses the kernel's network stack. This allows us to see exactly what the kernel is doing with each packet, providing unparalleled debugging capabilities.

`pwru`: Your Guide Through the Kernel Network Stack

While you could write your own eBPF programs to trace packets, tools like pwru (Packet Walk Ruler) abstract away the complexity, providing a ready-to-use solution for deep network stack inspection. pwru leverages eBPF to dynamically attach to numerous kernel functions and tracepoints, giving you a real-time, step-by-step view of a packet's journey.

Introducing `pwru`

pwru isn't just another tcpdump. It's a specialized tool designed to show you:

Hook Point: The specific kernel function or tracepoint the packet is currently passing through.
Action: What the kernel did with the packet at that point (e.g., PASS, CONSUMED, DROP, QUEUE).
Packet Metadata: Crucial details like source/destination IP/port, protocol, packet length (skb_len), network namespace, CPU, and more.
Context: Which netfilter hook, if any, was involved, and the return code.

This level of detail allows you to precisely identify where packets are being handled, modified, or dropped within the kernel, making it an indispensable tool for debugging complex network issues.

Setting Up `pwru` (Practical Steps)

pwru requires a relatively recent Linux kernel (4.9+ for basic eBPF, 5.x+ for full features and stability) and a few development tools to compile its eBPF programs.

Prerequisites:
- Linux Kernel: Version 4.9+ (5.x or newer recommended).
- Build Tools: clang, llvm, make, git.
- Kernel Headers: Ensure your kernel headers match your running kernel version. On Debian/Ubuntu, sudo apt install linux-headers-$(uname -r). On Fedora/CentOS/RHEL, sudo yum install kernel-devel.

Installation:
pwru is typically installed by cloning its GitHub repository and building it.

# Ensure you have git, clang, llvm, and make installed
sudo apt update && sudo apt install git clang llvm make   # For Debian/Ubuntu
# sudo yum install git clang llvm make                   # For Fedora/CentOS/RHEL

git clone https://github.com/cilium/pwru.git
cd pwru
make
sudo make install

If make install fails or you prefer not to install globally, you can run pwru directly from the pwru/bin directory.

Your First Packet Trace with `pwru`

Let's start with a simple example: tracing an HTTP request to a local web server (or any external website).

Open two terminal windows. In the first, start pwru:

# Terminal 1: Start pwru
# Trace TCP packets on port 80 (HTTP) or 443 (HTTPS)
# We'll customize output fields for clarity
sudo pwru --output-fields=src_ip,dst_ip,proto,port,func,action,skb_len \
          --filter "proto == IPPROTO_TCP && (dst_port == 80 || dst_port == 443)"

In the second terminal, make an HTTP request:

# Terminal 2: Make an HTTP request
curl -v http://example.com
# Or, if you have a local web server:
# curl -v http://localhost

Back in Terminal 1, you'll see a flood of output. Let's break down a typical line:

src_ip=192.168.1.100 dst_ip=93.184.216.34 proto=TCP port=51234->80 func=ip_rcv action=PASS skb_len=60
src_ip=192.168.1.100 dst_ip=93.184.216.34 proto=TCP port=51234->80 func=ip_local_deliver_finish action=PASS skb_len=60
src_ip=192.168.1.100 dst_ip=93.184.216.34 proto=TCP port=51234->80 func=tcp_v4_rcv action=PASS skb_len=60
... (many more lines) ...

What are we seeing? Each line represents a "hook point" – a specific kernel function or tracepoint – that the packet traversed.

src_ip, dst_ip, proto, port: Basic network tuple identifying the packet.
func: The kernel function name (ip_rcv, tcp_v4_rcv, etc.). This is the heart of pwru's insight.
action: What happened at that function. PASS means it continued its journey. DROP would indicate it was discarded. CONSUMED often means it was processed and removed from the general network path (e.g., by the TCP stack).
skb_len: The size of the sk_buff (socket buffer) structure carrying the packet data.

This output shows the packet moving through different layers and processing stages within the kernel. For an outgoing packet, you'd see functions like ip_output, dev_queue_xmit, etc. For an incoming packet destined for a local socket, you'd see ip_rcv, ip_local_deliver, tcp_v4_rcv, and eventually sock_queue_rcv_skb.

Deeper Dives: Understanding the Kernel Network Path

Interpreting pwru's output requires a basic understanding of how the Linux kernel processes network packets. While the full network stack is incredibly complex, we can identify key functions and their roles.

Key Kernel Hook Points and Their Significance

The kernel network stack can be broadly divided into ingress (receiving) and egress (transmitting) paths.

Ingress Path (Receiving a Packet):

__netif_receive_skb_core: The initial entry point for a packet received from the network driver.
ip_rcv: The entry point for IPv4 packets after __netif_receive_skb_core. It performs basic validation and determines if the packet is for the local host or needs forwarding.
ip_local_deliver_finish: If the packet is for the local host, this function is called. It passes the packet to the appropriate transport layer (TCP, UDP, ICMP).
tcp_v4_rcv / udp_rcv: Entry points for TCP and UDP packets, respectively, after ip_local_deliver_finish. These functions handle protocol-specific processing (e.g., TCP sequence number checks, ACK generation).
sock_queue_rcv_skb: The packet is finally queued to the receiving socket's buffer, making it available for a userspace application to read via recvmsg, read, etc.

Egress Path (Transmitting a Packet):

tcp_sendmsg / udp_sendmsg: Initiated by a userspace application's sendmsg or write call. These prepare the packet for transmission at the transport layer.
ip_output: Handles the IPv4 header creation and prepares the packet for sending.
ip_finish_output: Finalizes IP output, including routing decisions.
dev_queue_xmit: Queues the packet to the appropriate network device's transmit queue.
__dev_xmit_skb: The packet is handed off to the network driver for physical transmission.

pwru shows you the packet traversing many of these functions (and many more in between), along with netfilter hooks (NF_HOOK points) and other processing stages.

Common Scenarios & `pwru` Insights

Let's look at how pwru can help diagnose specific problems.

1. Pinpointing Packet Drops

One of the most powerful uses of pwru is identifying where and why a packet is dropped. If you suspect packet loss:

# Terminal 1: Watch for dropped packets
sudo pwru --output-fields=func,action,src_ip,dst_ip,proto,port,skb_len --filter "action == DROP"

Now, try to reproduce the packet loss (e.g., attempt a connection to a non-existent port on your machine, or trigger a firewall rule). You might see output like:

func=ip_rcv_finish action=DROP src_ip=192.168.1.1 dst_ip=192.168.1.100 proto=ICMP port=0->0 skb_len=84
func=nf_hook_slow action=DROP src_ip=192.168.1.1 dst_ip=192.168.1.100 proto=TCP port=12345->80 skb_len=60

ip_rcv_finish with DROP might indicate issues like a full receive queue or an invalid packet.
nf_hook_slow with DROP is a strong indicator that a netfilter (iptables) rule is dropping the packet. This immediately tells you to inspect your firewall configuration.

2. Analyzing Latency Attribution

If curl to localhost is slow, where is the time spent? pwru can show the timestamps for each hook point, though interpreting the exact delta requires careful analysis and often correlation with other tools. For a quick check, you can add ktime (kernel time in nanoseconds) to your output:

# Terminal 1: Trace a local request with timestamps
sudo pwru --output-fields=ktime,func,action,src_ip,dst_ip,proto,port,skb_len \
          --filter "proto == IPPROTO_TCP && (src_ip == 127.0.0.1 || dst_ip == 127.0.0.1) && (dst_port == 80 || src_port == 80)"

Then, in Terminal 2: curl http://localhost.

By examining the ktime values, you can see if there are unusually large gaps between consecutive func calls for the same packet. A long gap between ip_rcv and ip_local_deliver could suggest CPU contention or heavy processing before the packet reaches the transport layer. A delay between sock_queue_rcv_skb and the application's actual read might point to application-level slowness.

3. Understanding Firewall/Netfilter Interaction

pwru can explicitly show netfilter processing. netfilter hooks are points where iptables rules operate.

# Terminal 1: Trace packets, specifically looking for netfilter hooks
sudo pwru --output-fields=func,action,src_ip,dst_ip,proto,port,skb_len,hook_name,nf_verdict \
          --filter "proto == IPPROTO_TCP && (dst_port == 22 || src_port == 22)" # e.g., SSH traffic

You'll see lines like:

func=nf_hook_slow action=PASS hook_name=NF_INET_PRE_ROUTING nf_verdict=NF_ACCEPT src_ip=...
func=nf_hook_slow action=PASS hook_name=NF_INET_LOCAL_IN nf_verdict=NF_ACCEPT src_ip=...

hook_name: Specifies the netfilter hook (e.g., NF_INET_PRE_ROUTING, NF_INET_LOCAL_IN, NF_INET_FORWARD).
nf_verdict: The verdict of the netfilter chain (NF_ACCEPT, NF_DROP, NF_STOLEN, etc.).

If a packet is dropped by netfilter, you'll see an action=DROP along with nf_verdict=NF_DROP at a specific hook_name, telling you exactly which iptables chain is responsible.

4. Tracing Specific Connections

To focus on a single problematic connection, use detailed filters:

# Terminal 1: Trace a specific source IP and destination port
sudo pwru --output-fields=func,action,src_ip,dst_ip,proto,port,skb_len \
          --filter "src_ip == 10.0.0.5 && dst_port == 8080"

This ensures you only see the relevant packets, reducing noise and making analysis much easier. You can combine filters with AND, OR, NOT for very precise targeting.

Advanced `pwru` Techniques and Trade-offs

pwru is a powerful tool, and mastering its capabilities involves more than just basic tracing.

Filtering and Output Customization

Complex Filters: pwru supports complex logical expressions in its --filter argument.

# Trace HTTP and HTTPS traffic, but only from a specific source IP, and not if it's an ICMP packet
sudo pwru --filter "proto == IPPROTO_TCP && (dst_port == 80 || dst_port == 443) && src_ip == 192.168.1.10 AND NOT proto == IPPROTO_ICMP"

Custom Output Fields: The --output-fields argument is crucial. You can add fields like:
- cpu: Which CPU core processed the packet. Useful for identifying CPU affinity issues.
- ktime: Kernel timestamp (nanoseconds).
- netns: Network namespace ID. Essential in containerized environments.
- ifindex: Network interface index.
- mark: skb->mark value, often used for policy routing or firewall marking.
- tstamp: Hardware timestamp.
- ingress_ifindex, egress_ifindex: The interface the packet entered/exited.
- reason: Provides more context for drops.
Consult pwru --help for a full list of available fields.
Saving Output: Redirect pwru's output to a file for later analysis, especially for long-running traces.
```
sudo pwru --output-fields=... --filter "..." > pwru_trace.log
```

Performance Considerations

eBPF is designed for low overhead, but pwru attaches to many kernel hook points. On a very busy system with high packet rates, tracing every packet can still generate a substantial amount of data and consume CPU cycles.

Precision is Key: Always use the most precise filters possible. Instead of --filter "proto == IPPROTO_TCP", use proto == IPPROTO_TCP && (src_port == 12345 || dst_port == 8080) to focus on relevant traffic.
Output Fields: Only request the output fields you truly need. Each field adds a small amount of overhead.
Short Bursts: For initial diagnosis, run pwru for short bursts (e.g., 5-10 seconds) to capture a representative sample of traffic during a problem occurrence, rather than letting it run indefinitely.
Production Caution: While generally safe, running pwru on highly loaded production systems without careful filtering and monitoring should be approached with caution. Test your filters in a staging environment first.

Limitations and Alternatives

While pwru is incredibly powerful, it's not a silver bullet:

Kernel Knowledge Still Required: Interpreting the output, especially the func names, still requires some understanding of the kernel's network stack. You won't become a kernel expert overnight, but you'll learn key functions relevant to your debugging tasks.
Root Privileges: pwru requires root privileges to attach eBPF programs to the kernel.
Kernel Version Dependency: While pwru tries to be compatible, specific hook points or data structures can vary slightly between kernel versions, potentially affecting output or functionality.
Not a Packet Capture Tool: pwru shows kernel events, not the full packet payload. For payload inspection, tcpdump or Wireshark are still necessary.

Alternatives and Complementary Tools:

BCC Tools: The BPF Compiler Collection (BCC) provides a rich set of eBPF-based tools for various aspects of kernel observability, including networking (e.g., tcplife, dropwatch, sockstat). They are often more specialized than pwru.
bpftrace: If pwru's predefined tracing isn't enough, bpftrace allows you to write custom eBPF one-liners or scripts with a simpler syntax than raw C. This is for when you need to combine specific kernel events or perform custom aggregations.
tracepoint-analyzer: Another tool specifically designed to help understand kernel tracepoints.

pwru serves as an excellent starting point and often provides enough detail for most network debugging scenarios. When you hit its limits, bpftrace or specialized BCC tools are the next logical step.

Conclusion

The journey of a packet through the Linux kernel is often an invisible one, a black box that can hide the root causes of frustrating network performance issues, mysterious packet drops, and elusive latency. For too long, developers have been forced to debug these problems with limited visibility, relying on guesswork and external network tools that only show part of the picture.

eBPF has fundamentally changed this landscape, empowering us to safely and efficiently peer into the kernel's inner workings. Tools like pwru democratize this power, translating complex kernel events into actionable insights that even developers "who barely know the kernel" can understand and leverage.

By embracing pwru and its eBPF underpinnings, you gain a superpower: the ability to trace a packet's every step, understand its fate, and pinpoint precisely where things go wrong within the operating system. This deeper understanding

Router Configuration Theft: How Far Should Credential Rotation Go?

Sat, 18 Jul 2026 18:32:19 +0000

A copied router configuration creates two response problems. One is the compromised device. The other is every credential, trusted source, and management path described inside the file.

Rebuilding the router addresses the first problem. It does not automatically contain the second.

That distinction matters in the activity described by the joint router-security advisory released July 13, 2026. The participating agencies attributed the campaign to actors associated with Center 16 of Russia's Federal Security Service.

The reported technique is not especially exotic. The actors scan for routers that accept legacy SNMP, try weak or default community strings, and issue SNMP Set requests that invoke supported configuration-copy functions. The router then transfers its own configuration, typically over TFTP, to external infrastructure.

There may be no implant or suspicious process chain to find. A legitimate management function performs the export.

The file changes the containment boundary

A router configuration can contain local credentials, SNMP community strings, management addresses, access-control rules, routes, interface descriptions, neighboring systems, and trusted source addresses.

Not every item is a reusable secret. The collection still has operational value.

Routes and interface descriptions help map the environment. Access-control rules identify permitted sources. Management settings point toward monitoring, authentication, and administrative systems. Even strongly protected passwords do not hide those relationships.

The FBI has documented both configuration collection and further activity in this campaign. In an August 2025 warning, it reported that Center 16 actors had collected configurations from thousands of networking devices associated with US critical-infrastructure entities during the preceding year.

On some vulnerable devices, the actors modified configurations to enable unauthorized access. They used that access for reconnaissance that revealed interest in protocols and applications associated with industrial control systems.

The FBI did not say that every collected configuration contained reusable credentials. It also did not establish that each collection event led to deeper access. It did document configuration collection, device modification, and downstream reconnaissance within the same campaign.

That is enough to make a router rebuild an incomplete containment decision.

Rotation is a dependency problem

The difficult question is not whether a credential exposed in the file should be changed. It is how far that change must extend.

A shared SNMP community string may be accepted by an entire device class. A reused local administrator credential may work across sites. A management server address may appear in many allowlists. The NCSC's router guidance pairs management-source allowlists with boundary anti-spoofing so a trusted source cannot simply be impersonated from outside the network.

Rotating everything immediately can disrupt monitoring, automation, backups, and emergency access. Rotating only the affected router can leave the attacker with valid access elsewhere.

A practical response starts by separating four questions:

Was a configuration exported, and where was it sent?
Which credentials or shared secrets were present in that version of the configuration?
Where else were those credentials or trust relationships accepted?
What changed on the router or adjacent management systems?

The third question is where inventory quality becomes incident-response capability. If the team cannot identify every device that accepts a community string or local account, it cannot confidently describe the remaining exposure.

Detection has the same dependency issue

The advisory supplies example Cisco object identifiers for configuration-copy monitoring. One identifies the ccCopy subtree. Another identifies a destination server address.

The cited destination-address object, ccCopyServerAddress, is deprecated and limited to IPv4. Newer implementations can use ccCopyServerAddressType and ccCopyServerAddressRev1.

An exact-match detector built only from the two examples can therefore miss a valid transaction using the replacement address object. Prefix matching on the ccCopy subtree, combined with monitoring for SNMP Set requests, covers that case.

Outbound controls are part of the same detection model. If a router can initiate arbitrary TFTP transfers, the configuration-copy function already has an exit path. External TFTP should be blocked unless it is operationally required, then closely monitored where it cannot be blocked.

Device logs also need to exist somewhere other than the device. A compromised router should not be the only custodian of evidence about its own management activity.

SNMPv3 is necessary, but scope still matters

The joint advisory and the NSA's guidance on reducing SNMP abuse recommend SNMPv3 with authPriv, which adds authentication and encryption.

NSA also states that SNMPv3 alone is insufficient. A compromised or over-privileged SNMPv3 credential can still reach sensitive objects unless its permissions are constrained.

The stronger design separates read and write authority, limits accessible objects through MIB views, restricts management traffic to approved systems, separates the management network where practical, monitors configuration-copy operations, and blocks unnecessary outbound management protocols.

Where older equipment or management software cannot support authPriv, NSA identifies authNoPriv as the fallback but still directs operators to upgrade.

The immediate inventory is therefore broader than a list of legacy SNMP versions. It also needs to show where management credentials are reused, which systems can issue write operations, and which destinations the infrastructure itself can reach.

For teams supporting mixed generations of network equipment, the unresolved tradeoff is sequencing. If configuration history is uncertain and the credential inventory is incomplete, do you rotate shared credentials across the reachable device class immediately and accept the outage risk, or contain management traffic first while building the reuse map?

That decision belongs in the incident runbook before a router exports its own configuration.

HTTP Status Codes Explained with a Resturant Analogy

Wed, 15 Jul 2026 05:29:10 +0000

You order food.The kitchen responds.That's literally what HTTP is - and once you get this, servers will never feel mysterious again.

A little backstory

I'm a newcomer to web development, and for the longest time, servers and HTTP felt like some dark magic I wasn't supposed to understand yet. That changed when I started working on my ASCII-ART-WEB project at Zone01.

The project required me to build an actual HTTP server from scratch — handling requests, sending responses, setting the right status codes. Suddenly all of this wasn't theoretical anymore. I had to understand it. And when it clicked, it clicked hard.

This article is me passing that click on to you, using the analogy that finally made it stick.

The internet is a restaurant

Seriously. Every time you type a URL into your browser, you're basically sitting at a table and calling a waiter over.

HTTP stands for HyperText Transfer Protocol. It's just the agreed-upon language that lets your browser and the server talk to each other. Nothing more mysterious than that.

Every page load is a tiny round-trip conversation:

Browser → [HTTP request] → Server → [HTTP response + status code] → Browser renders the page

Step by step:

You type a URL and hit Enter
Your browser sends an HTTP request to the server at that address
The server receives the request and processes it
The server sends back an HTTP response — which includes the data (a webpage, an image, JSON, etc.) and a status code
Your browser reads the status code, then renders the page

That status code is the kitchen's way of telling the waiter how the order went before the food even leaves the counter.

What an HTTP request actually looks like

When your browser asks for a page, it sends something like this under the hood:

GET /menu HTTP/1.1
Host: restaurant.com
Accept: text/html

And the server replies:

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 3456

<!DOCTYPE html>
...

That 200 at the top? That's the status code. It's the first thing the browser checks.

The four status codes every dev must know

There are over 60 official HTTP status codes, but these four will cover 90% of what you encounter day-to-day.

200 — OK

"The food arrived hot and exactly as ordered."

The happy path. The server found what you asked for, processed everything correctly, and sent it back. This is what you want to see on every request.

400 — Bad Request

"You ordered in a language the kitchen doesn't understand."

This means the request itself was broken — maybe it was missing required data, had invalid formatting, or sent something the server just can't parse. It's a client-side error, meaning the problem is in the request you sent, not the server.

404 — Not Found

"We checked the whole fridge. That dish doesn't exist here."

The server is working fine, but the specific thing you asked for — that URL, that file, that route — simply doesn't exist. Classic example: you mistype a URL, or someone deleted a page that used to exist.

500 — Internal Server Error

"The oven exploded. It's not your fault — something broke inside the kitchen."

The server tried to handle your request but something went wrong in its own code. This is a server-side error. As the user, you did nothing wrong. As the developer, this is where you open your logs and start debugging.

The golden rule of status codes

4xx = The customer's fault
5xx = The kitchen's fault

Memorise this. When you're debugging and you see a 4xx, look at what you're sending. When you see a 5xx, look at what the server is doing with it.

The full status code family tree
Status codes are grouped by their first digit:
1xx-Informational-"Hold on,still cooking.."
2xx-Success-"Here's your food,enjoy"
3xx-Redirection-"Wrong table-they're at table 7 now"
4xx-Client error-"Your order is the problem"
5xx-Server error-"The kitchen is having a moment"

A few other useful ones you'll bump into:

201 Created — used in APIs when something new was successfully created (like a new user account)
301 Moved Permanently — the URL has changed forever, the server redirects you
401 Unauthorized — you need to log in first
403 Forbidden — you're logged in but you're not allowed to access this
422 Unprocessable Entity — the server understood your request but couldn't process it (common in form validation)

How ASCII-ART-WEB helped me understand all of this

When I was working on the ASCII-ART-WEB project at Zone01, I had to build an HTTP server in Go that:

Received a POST request with text from a web form
Converted that text into ASCII art using a banner file
Sent back the result as an HTTP response

At first, I was just copying status codes without understanding them. Then I hit a bug: my server was sending 200 OK even when the input was invalid.

A user would send an empty form — technically a bad request — and my server was responding like everything was fine. That's when the restaurant analogy hit me: if a customer orders nothing, the kitchen shouldn't just send back an empty plate with a smile. It should say "400 — your order doesn't make sense."

Once I fixed that, my server started behaving like a real server:

go// If the form input is empty, respond with 400
if userText == "" {

http.Error(w, "400 - Bad Request: input cannot be empty", http.StatusBadRequest)
return

}

// If the banner file doesn't exist, respond with 404
if _, err := os.Stat(bannerFile); os.IsNotExist(err) {

http.Error(w, "404 - Banner file not found", http.StatusNotFound)
return

}

// If something unexpected breaks, respond with 500
http.Error(w, "500 - Internal Server Error", http.StatusInternalServerError)

Suddenly HTTP wasn't abstract theory. Every status code had a job. Every response had a reason. The restaurant wasn't just an analogy anymore — it was the mental model I used every time I wrote a handler.

Try it yourself right now

Open your browser, press F12, and go to the Network tab. Reload any webpage.

Every single row you see is an HTTP request, with its status code right there in the Status column. Watch the 200s flood in as the page loads. Try visiting a broken URL and watch the 404 appear. This is how real developers debug every single day — and seeing it live is the fastest way to make everything in this article click.

Wrapping up

HTTP is just two sides talking to each other — a customer and a kitchen. Status codes are how the kitchen reports back. Once you stop thinking of them as mysterious numbers and start thinking of them as kitchen updates, the whole web starts making more sense.

If you're working on any project that touches a server — even a small one like ASCII-ART-WEB — I'd genuinely encourage you to try building a basic HTTP handler yourself. Reading about status codes is one thing. Returning the wrong one and watching your app break in a confusing way is what actually teaches you.

Thanks for reading! If you found this helpful or you're also a newcomer grinding through your first server project, drop a comment — I'd love to hear what you're building.Alsoo don't forget to fllow and connect with me on linked in @mayan okul

Status:200 OK.This article:served

I built a dependency-free Remote Exec Server in Python using BusyBox-style symlinks

Sun, 21 Jun 2026 16:27:42 +0000

I wanted to see how minimal a remote command execution system could be when restricted entirely to the Python standard library. No external dependencies. No frameworks. Just clean, standard networking primitives.

The result: Remote Exec Server & Client — a two-file system (server.py + client.py) with a BusyBox-style symlink architecture.

👉 github.com/foxhackerzdevs/remote-exec-server

The Problem

I run PARI/GP on a remote machine and wanted to pipe expressions to it from my local terminal — without SSH overhead, without installing PARI/GP locally, and without a heavyweight RPC framework.

The simplest possible solution: an HTTP server that accepts a command + stdin, runs it, and returns stdout.

The BusyBox Idea

BusyBox is a single binary that behaves differently depending on the name it's invoked under. ls, cp, mv — all the same binary, different symlinks.

I applied the same pattern to client.py. You create symlinks named after tools installed on the server:

ln -s client.py gp
ln -s client.py python
ln -s client.py node

When you invoke a symlink, client.py reads sys.argv[0] to determine which command to forward. That command, plus any arguments and stdin, gets packed into an HTTP POST request.

How It Works

server.py (streams stdout AND stderr live, concurrently; optional whitelist and TLS)

#!/usr/bin/env python3
from http.server import BaseHTTPRequestHandler, HTTPServer
import subprocess, urllib.parse, shlex, os, sys, threading, queue, ssl

VERSION = "1.5.0"

# Comma-separated allowed commands via REMOTE_EXEC_ALLOWED env var.
# Empty/unset = allow everything (original default behavior).
_allowed_env = os.environ.get("REMOTE_EXEC_ALLOWED", "")
ALLOWED = {c.strip() for c in _allowed_env.split(",") if c.strip()}

# TLS cert/key paths via env vars. Unset = plain HTTP (original default).
TLS_CERT = os.environ.get("REMOTE_EXEC_TLS_CERT", "")
TLS_KEY  = os.environ.get("REMOTE_EXEC_TLS_KEY", "")

class MyHandler(BaseHTTPRequestHandler):
    def do_POST(self):
        content_length = int(self.headers.get('Content-Length', 0))
        body = self.rfile.read(content_length)

        raw_path = urllib.parse.unquote(self.path.lstrip("/"))
        try:
            cmd_parts = shlex.split(raw_path)
        except ValueError as e:
            self.send_response(400)
            self.end_headers()
            self.wfile.write(f"Error: could not parse command: {e}\n".encode())
            return

        if not cmd_parts:
            # e.g. a bare POST to "/" -- used to crash with an uncaught
            # IndexError on the next line instead of failing cleanly.
            self.send_response(400)
            self.end_headers()
            self.wfile.write(b"Error: no command specified.\n")
            return

        cmd_parts[0] = os.path.basename(cmd_parts[0])

        if ALLOWED and cmd_parts[0] not in ALLOWED:
            self.send_response(403)
            self.send_header("Content-Type", "text/plain; charset=utf-8")
            self.end_headers()
            self.wfile.write(f"Error: command '{cmd_parts[0]}' is not allowed.\n".encode())
            return

        try:
            process = subprocess.Popen(
                cmd_parts,
                stdin=subprocess.PIPE,
                stdout=subprocess.PIPE,
                stderr=subprocess.PIPE
            )

            self.send_response(200)
            self.send_header("Content-Type", "text/plain; charset=utf-8")
            self.send_header("Transfer-Encoding", "chunked")
            self.end_headers()

            # stdin is written, and stdout/stderr are read, by THREE
            # concurrent threads -- not sequentially. Writing all of
            # stdin first (as a single blocking call, before anything
            # drains stdout/stderr) deadlocks for any command whose
            # input exceeds the OS pipe buffer (~64KB on Linux): the
            # child fills its stdout pipe and blocks since nobody's
            # reading yet, stops consuming stdin, and the write then
            # blocks too. Same deadlock subprocess.communicate() avoids
            # internally by handling all streams at once.
            line_queue = queue.Queue()

            def reader(stream, prefix):
                for line in stream:
                    line_queue.put(prefix + line if prefix else line)
                line_queue.put(None)

            def stdin_writer(proc, data):
                try:
                    if data:
                        proc.stdin.write(data)
                except BrokenPipeError:
                    pass  # process exited without reading all of stdin
                finally:
                    try:
                        proc.stdin.close()
                    except OSError:
                        pass

            t_in = threading.Thread(target=stdin_writer, args=(process, body))
            t_out = threading.Thread(target=reader, args=(process.stdout, b""))
            t_err = threading.Thread(target=reader, args=(process.stderr, b"[stderr] "))
            t_in.start(); t_out.start(); t_err.start()

            done = 0
            while done < 2:
                chunk = line_queue.get()
                if chunk is None:
                    done += 1
                    continue
                self.wfile.write(f"{len(chunk):X}\r\n".encode())
                self.wfile.write(chunk)
                self.wfile.write(b"\r\n")
                self.wfile.flush()

            t_in.join(); t_out.join(); t_err.join()
            process.wait()
            self.wfile.write(b"0\r\n\r\n")
        except FileNotFoundError:
            self.send_response(200)
            self.end_headers()
            self.wfile.write(f"Error: command not found: {cmd_parts[0]}\n".encode())

if __name__ == "__main__":
    if "--version" in sys.argv or "-V" in sys.argv:
        print(f"remote-exec-server {VERSION}")
        sys.exit(0)

    server = HTTPServer(("0.0.0.0", 8000), MyHandler)

    if TLS_CERT and TLS_KEY:
        ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
        ctx.load_cert_chain(certfile=TLS_CERT, keyfile=TLS_KEY)
        server.socket = ctx.wrap_socket(server.socket, server_side=True)
        print(f"Serving HTTPS on 0.0.0.0:8000 (cert: {TLS_CERT})")
    else:
        print("Serving HTTP on 0.0.0.0:8000")

    server.serve_forever()

The first streaming version only read stdout live and grabbed stderr after the fact — which meant stderr output on a successful exit was silently dropped, and a subprocess that filled its stderr pipe buffer while only stdout was being drained could deadlock entirely. Two reader threads plus a shared queue fixed both: stdout and stderr now interleave live, with stderr lines prefixed [stderr] so they're distinguishable in the client's terminal.

Update (v1.5.0): that fix covered stdout/stderr, but missed a related deadlock on the stdin side — writing the entire request body to the subprocess in one blocking call, before the reader threads even started, hangs the whole server (it's single-threaded) for any command whose stdin exceeds the OS pipe buffer, roughly 64KB on Linux. A third thread now writes stdin concurrently with the stdout/stderr readers, the same way subprocess.communicate() avoids this internally. v1.5.0 also fixes an uncaught crash on an empty command path (a bare POST / used to throw an IndexError instead of failing cleanly) and adds --version.

client.py (streams the response line by line; optional TLS)

#!/usr/bin/env python3
import http.client, sys, urllib.parse, os, ssl

VERSION = "1.5.0"

# Can't be a --version flag: this script forwards everything it's
# invoked with -- symlink name and all arguments -- to the server as
# the remote command. A local --version flag would be indistinguishable
# from someone legitimately checking a *remote* command's version (e.g.
# `python --version` via a `python` symlink), so it's an env var instead.
if os.environ.get("REMOTE_EXEC_CLIENT_VERSION", "") == "1":
    print(f"remote-exec-client {VERSION}")
    sys.exit(0)

host = "192.168.56.1:8000"

# TLS via env vars. REMOTE_EXEC_TLS_INSECURE skips cert verification —
# only for self-signed certs during local testing.
use_tls = os.environ.get("REMOTE_EXEC_TLS", "") == "1"
insecure = os.environ.get("REMOTE_EXEC_TLS_INSECURE", "") == "1"

if use_tls:
    ctx = ssl.create_default_context()
    if insecure:
        ctx.check_hostname = False
        ctx.verify_mode = ssl.CERT_NONE
    conn = http.client.HTTPSConnection(host, context=ctx)
else:
    conn = http.client.HTTPConnection(host)

# Avoid a trailing %20 in the path when no arguments are given
cmd_str = sys.argv[0]
if len(sys.argv) > 1:
    cmd_str += " " + " ".join(sys.argv[1:])
path = "/" + urllib.parse.quote(cmd_str)

body = sys.stdin.buffer.read()
conn.request("POST", path, body=body, headers={"Content-Type": "text/plain; charset=utf-8"})

response = conn.getresponse()
for line in response:
    sys.stdout.buffer.write(line)
    sys.stdout.buffer.flush()

The protocol

The command and arguments travel in the URL path. Stdin travels in the request body. Stdout comes back in the response body. That's the entire protocol.

POST /gp%20-q HTTP/1.1
Host: 192.168.56.1:8000
Content-Type: text/plain

print(nextprime(100))

In Action

# Start the server on the remote machine
python server.py

# On the client machine
ln -s client.py gp
echo "print(nextprime(100))" | ./gp -q
# → 101

The Elephant in the Room: Security

This maps HTTP payloads directly to a subprocess call. That's RCE by design. The baseline implementation has no authentication, no rate limiting, and TLS is opt-in rather than default.

I built it this way intentionally — as a minimal blueprint that forces the operator to consciously design their own security layer rather than rely on defaults that provide a false sense of security.

Before any real deployment, the README covers:

Command whitelisting: Built in as of v1.3.0 — set an environment variable before starting the server:

REMOTE_EXEC_ALLOWED="gp,python,node" python server.py

Unset or empty allows everything (the original default). Disallowed commands get a 403 before the subprocess is even spawned.

Encryption: Built in as of v1.4.0 — set cert/key paths on the server and a flag on the client:

# Server
REMOTE_EXEC_TLS_CERT=cert.pem REMOTE_EXEC_TLS_KEY=key.pem python server.py

# Client (add REMOTE_EXEC_TLS_INSECURE=1 for self-signed certs during local testing)
REMOTE_EXEC_TLS=1 python client.py

Unset means plain HTTP, same as before. For local testing, generate a throwaway cert with openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365 -nodes -subj "/CN=localhost".

Network isolation: Bind to 127.0.0.1 and route through an SSH tunnel or VPN.

Sandboxing: Run the server inside a Docker container with restricted permissions.

What's Next

The core engine is solid. Real-time output streaming shipped in v1.2.0, command whitelisting in v1.3.0, TLS in v1.4.0, and a couple of real bugs — a server-wide stdin deadlock and a crash on malformed requests — got fixed in v1.5.0. The roadmap includes:

Native API-key and mTLS authentication
Async request handling
Pre-configured Docker deployment

Contributions welcome — especially on the security and async fronts.

👉 github.com/foxhackerzdevs/remote-exec-server