Appendix E: Network Bridge — Reaching Devices Through Tailscale

This appendix is a step-by-step manual for the Network Bridge feature in the AutoCore Console. It is written assuming you have never used Tailscale before, do not necessarily know what an IPv6 address is, and have not edited a hosts file. If any of those describe you, you are the audience for this chapter — read it in order.

If you already know Tailscale and just want the operational reference, skip to Quick Reference at the end.

The chapter is in two halves:

Part 1: For Administrators is for the person who has admin access to your company’s Tailscale account (the “tailnet admin”). You configure the bridge once per project, approve the route, and hand a small piece of text to the developers.
Part 2: For Developers and Users is for everyone else — people who need to reach a device through the bridge from their own laptop but do not have admin access.

A Glossary at the end defines every term used here.

What this feature does

The embedded computer running autocore-server is normally connected to two networks at once:

Tailscale — a private virtual network that lets you reach the embedded computer from anywhere in the world, as long as your laptop is also signed in to the same company tailnet.
The process network — a small, isolated LAN on the embedded computer’s second adapter, typically using the address range 192.168.127.x. The PLC, NI rack, panel PC, industrial robot, and other field devices live on this LAN. The embedded computer is the only thing connected to both networks.

Out of the box, your laptop can only reach the embedded computer itself. You cannot reach the other devices on the process network because Tailscale does not know about them, and those devices have no direct connection to the Internet.

The Network Bridge feature solves this by telling Tailscale to act as a router: traffic on the tailnet destined for the process network is forwarded through the embedded computer, which already knows how to talk to those devices. Once configured, your laptop can reach the panel PC, the NI rack, and any other device on the process network just by typing its address — almost as if your laptop were sitting in the lab next to it.

When to use it (and when not to)

Use the Network Bridge when:

You need to open the panel PC’s web UI from your desk to check a HMI screen.
You need to talk to an NI rack’s measurement service over its native TCP/UDP protocol.
You need to push firmware or programs to an industrial robot whose proprietary tool only knows how to talk on the local LAN.
Anything else where “I wish I could be on that LAN” is the right shape of the problem.

Do not use the Network Bridge for:

Running production HMIs over a flaky Internet link. Tailscale is reliable, but field-side latency and bandwidth still apply.
Letting people outside your company access these devices. Tailscale is private to your tailnet, but inside your tailnet it is wide open by default. If sensitive devices live on the process network, ask the admin to set up Tailscale ACLs (out of scope for this manual).

Concepts you need to know

Five terms come up over and over. Skim these now; come back to the glossary if you forget what one of them means later.

Tailscale is a software tool that builds a private virtual network (“tailnet”) between computers. When two computers are signed in to the same tailnet, they can talk to each other no matter where they are physically.
Subnet routing is a Tailscale feature where one node on the tailnet (here: the embedded computer) declares “I can reach the following address range on a network you can’t see; if you send me traffic for that range, I’ll forward it.” Other computers on the tailnet then treat that range as if it were directly reachable.
IPv4 vs IPv6 — there are two flavours of Internet addresses. IPv4 looks like 192.168.127.5. IPv6 looks like fd7a:115c:a1e0:b1a:0:ef9:c0a8:7f05. Tailscale uses both. Modern laptops and operating systems handle both transparently — you just have to type the right kind of address.
4via6 (pronounced “four via six”) is a specific Tailscale trick we use to solve a problem you’ll hit if you have more than one ADC machine in the field. Every ADC embedded computer uses the same 192.168.127.x address range internally. If both machines just advertised that range straight, Tailscale wouldn’t know which one you meant. 4via6 gives each machine a unique IPv6 address space that maps onto its own copy of the 192.168.127.x range. From your laptop, you address devices by IPv6; Tailscale translates back to IPv4 at the embedded computer.
Site ID is the number that distinguishes one machine’s 4via6 space from another’s. Every ADC machine is given a site ID at setup time; it is the same number as the serial number on the chassis sticker (adc-sn-3833 → site ID 3833). You will see this number embedded in the IPv6 addresses the console produces.

Quick reference

If you are already familiar with everything above:

Admins: Console → Network Bridge tab → click Advertise on the local subnet → open the Tailscale admin console (login.tailscale.com) → Machines → click your node → Edit route settings → approve the fd7a:115c:a1e0:b1a:0:<site_id>::/96 route → back in AutoCore, Scan and label devices → click Copy block under “Hosts-file snippet” → send to users.
Users: Install Tailscale, sign in to the company tailnet, ask your admin for the hosts snippet they generated, paste it into your laptop’s hosts file, then use the friendly names (e.g. panel-pc-3833) in your browser or other tools.

The rest of this appendix walks through each of those steps slowly.

Part 1: For Administrators

This part is for the person who has admin access to the Tailscale admin console at login.tailscale.com. If you do not, skip to Part 2 — but it will be useful to read this part too so you understand what your admin is doing.

1.1 Prerequisites — what must already be true

Before you set up a Network Bridge, the following must be true. The short version: the embedded computer must be on both networks and Tailscale must already be working.

The embedded computer is running autocore-server. If you can reach the AutoCore Console in your web browser, this is already true.
Tailscale is installed and signed in on the embedded computer. You can verify by SSHing to the embedded computer and running:
```
tailscale status
```
The first line of the output should not say “Logged out.” If it does, run sudo tailscale up and sign in following the URL it prints. You only do this once.
You have admin (Owner or Admin role) access to the company tailnet at login.tailscale.com. If you can see other people’s machines in the Machines panel when you sign in, you have the right level of access.
The embedded computer is connected to the process network. Run:
```
ip -4 addr show
```
You should see at least two adapters with addresses — for example, one on 192.168.x.x (the customer’s office network or a router) and one on 192.168.127.1 (the process network). The exact numbers depend on the project.

If any of those four things is not true, fix them first. The rest of this appendix assumes they are all in place.

1.2 Open the Network Bridge tab in the console

In your web browser, go to the AutoCore Console URL for the embedded computer. This will be something like:
```
http://adc-sn-3833/console
```
or, if name resolution isn’t set up, the embedded computer’s Tailscale IPv4 address — find it by running tailscale ip -4 on the embedded computer.
At the top of the console you will see two tabs: Console and Network Bridge. Click Network Bridge.
The page that loads has four sections, top to bottom:
1. Network Bridge header — your machine’s identity.
2. Local Subnets — the LANs the embedded computer is connected to.
3. Devices on <address> — devices the embedded computer can see on a chosen subnet.
4. Hosts-file snippet — the text you will send to your users.

The rest of this part walks through them in order.

1.3 Reading the header

The Network Bridge header tells you four things. Take a moment to find each of them on screen now:

Hostname: should be something like adc-sn-3833. This is the name of the embedded computer.
Site ID: a number, usually equal to the serial number in the hostname (3833 in the example above). The label (from hostname) means it was parsed automatically. (from config) means someone set an override in the configuration file.
4via6 prefix: an IPv6 address ending in ::/96, like fd7a:115c:a1e0:b1a:0:ef9::/96. This is the unique IPv6 space reserved for this embedded computer. The ef9 part is the hexadecimal form of the site ID (3833 in decimal = ef9 in hex). You do not need to do this conversion yourself; the console does it.
Tailscale state: a small badge that should say Running. If it says NeedsLogin or Stopped, go back to step 1.1.2 and finish setting up Tailscale before continuing.

If anything in the header looks wrong (for example, the site ID is “could not derive”), stop and address it before proceeding. Common fixes:

“Could not derive site_id from hostname” — the embedded computer was hostnamed something other than adc-sn-NNNN. Either rename the machine (sudo hostnamectl set-hostname adc-sn-3833, then reboot) or add a [bridge] site_id = 3833 entry to /opt/autocore/config/config.ini and restart autocore_server.

1.4 Advertise the local subnet

Find the Local Subnets section. It lists every IPv4 network the embedded computer is currently connected to.

You want to advertise the process network — the one with the field devices on it. In a typical project that’s the 192.168.127.x/24 network. Do not advertise the customer’s general office network or a network connected directly to the Internet, both of which would expose far more than you intend.

Find the row whose CIDR column begins 192.168.127. (The CIDR is the address-and-prefix notation you see in the column; on a typical ADC machine you’ll see 192.168.127.1/24.)
Click the Advertise button at the right of that row.
The page will refresh after a moment. You should see two things change:
- A new orange notice appears below the table: “Route is advertised but not yet approved…”
- The Tailscale state badge area now also shows Approval pending.

The embedded computer is now telling the Tailscale admin server “please let other tailnet members reach my process network through me.” But until you approve that request, nobody actually can. The next step is approving it.

1.5 Approve the route in the Tailscale admin console

This is the only step that happens outside the AutoCore Console.

In a new browser tab, go to:
```
https://login.tailscale.com
```
Sign in if you aren’t already.
You will see a list of “machines” — every device signed in to your tailnet. Find the row for the embedded computer (its name will be the hostname, e.g. adc-sn-3833).
There may be a yellow badge or icon next to that row that says “Subnets” or shows a number — that is Tailscale’s way of telling you the machine has unapproved routes waiting.
Click the row to open the machine’s details. (On some Tailscale UI versions you instead click the three-dot menu at the right of the row and choose Edit route settings.)
You will see a section labelled Subnet routes with the advertised route listed — it will be the same long IPv6 address you saw in the AutoCore Console header, ending in ::/96. There will be a checkbox or toggle next to it.
Tick the checkbox to approve the route.
Click Save (button label varies by Tailscale version).
Switch back to the AutoCore Console browser tab. Click the Refresh button at the top of the Network Bridge panel.
The orange “Approval pending” notice should disappear, and you should see a green Route approved tag in the header.

The bridge is now live. Devices on the process network are reachable from any laptop on your tailnet — but only at IPv6 addresses your users would not know offhand. The next sections fix that.

1.6 Scan and label devices

Without labels, your users have to remember that the panel PC is at fd7a:115c:a1e0:b1a:0:ef9:c0a8:7f64. With labels, they can type panel-pc-3833 instead. Setting labels is worth the few minutes.

In the Local Subnets table, click Pick on the process network row to select it as the scan target.
Scroll down to Devices on 192.168.127.1 (or whatever your local address is).
Click Scan. The button label changes to Scanning… for a couple of seconds, then a table populates.

What’s happening: the console asks the kernel “what devices have you seen on this network adapter recently?” It then sends a ping to every address in the range to wake up devices that have been quiet, and asks the kernel again.
For each device you recognise:
- Type a label in the Label column (e.g. NI Rack, Panel PC, Robot 1).
- Click the small save icon to the right of the input.
Labels are saved in /opt/autocore/config/config.ini and survive restarts.
Devices you don’t recognise can be left alone. Devices that are just other ADC machines (look at the MAC column — anything starting with a familiar ADC MAC prefix) don’t need labels.

The IPv6 (4via6) column shows the address your users will actually type. There is a copy button at the right of each cell.

1.7 Build and distribute the hosts snippet

The hosts snippet is the bridge between the long IPv6 addresses and the friendly names you just typed in.

Scroll to the Hosts-file snippet section at the bottom of the page. After the scan, the box should now contain several lines.
The block looks something like this — this is exactly what your users will paste:
```
# autocore Network Bridge — site_id 3833 (adc-sn-3833) — 4via6 prefix fd7a:115c:a1e0:b1a:0:ef9::/96
fd7a:115c:a1e0:b1a:0:ef9:c0a8:7f05	ni-rack-3833
fd7a:115c:a1e0:b1a:0:ef9:c0a8:7f14	robot-3833
fd7a:115c:a1e0:b1a:0:ef9:c0a8:7f64	panel-pc-3833
```
The -3833 suffix on every name is the site ID — it disambiguates this site from any other ADC machine your users might also have access to. If a developer works on three projects, they can paste three blocks into their hosts file and end up with panel-pc-3833, panel-pc-4012, panel-pc-4509 all distinct.
Click Copy block. The full text is now on your clipboard.
Send it to every developer who needs access. Email, Slack, your team’s wiki — anywhere is fine. There is no secret material in the block; it is safe to share.

The text in the box is regenerated every time you change a label; you do not need to manually keep it in sync. After you add or rename labels, hit Rebuild then re-send.

1.8 Disabling or changing the bridge

To stop advertising the route (because the project is over, the embedded computer is being retired, or you suspect a security issue):

In the Local Subnets table, click Disable on the row whose bridge is currently active.
The route is removed immediately from the advertised list. Note that this is asymmetric: the Tailscale admin console may continue to list the route as approved, but the embedded computer is no longer advertising it, so traffic stops.
If you also want to revoke approval in the admin console for cleanliness:
- Go back to login.tailscale.com → Machines → your node → Edit route settings → uncheck the route → Save.

To advertise a different subnet, click Disable first, then Advertise on the new row.

The bridge can only advertise one process subnet at a time — that’s the model the feature is designed around. If you need two distinct subnets routed, contact ADC; we’ll add the configuration knobs.

1.9 Troubleshooting for administrators

“I clicked Advertise but nothing happened.” Check the Tailscale state badge. If it says Stopped or NeedsLogin, the underlying Tailscale daemon isn’t ready. SSH to the embedded computer and run sudo tailscale up.

“The Route approved tag never appears.” You probably didn’t tick the checkbox in the Tailscale admin console, or you saved the page without committing. Reload login.tailscale.com, find the node, and check the route’s state. Tailscale’s UI sometimes places the save button in a sub-modal — make sure you see a confirmation toast that says the change was saved.

“A user says ‘I can’t reach panel-pc-3833’.” Walk through these, in order:

Is the route still approved on this node? — Check the green Route approved badge in the console. If it’s missing, you’ve regressed to step 1.5.
Is the device actually on? — Use the Scan button. If the device doesn’t appear, or appears with state FAILED, the embedded computer can’t reach it locally, so a remote user definitely can’t.
Does the user have Tailscale running and signed in to the right tailnet? — Easy to forget; especially common after the user’s laptop reboots and Tailscale didn’t auto-start.
Did the user copy the latest hosts snippet? — If you renamed labels recently, the user may have an out-of-date block in their hosts file. The IPv6 itself hasn’t changed (it’s tied to the device’s IPv4), but the names might have.
Is something on the customer’s network blocking outbound IPv6 to the embedded computer? — Rare, but possible behind aggressive corporate firewalls. See Glossary: 4via6 for what traffic is actually flowing.

“I see two ADC machines advertising the same site ID.” This shouldn’t happen — site IDs come from machine serials and serials are unique — but if it does (e.g., someone manually overrode the site_id in config.ini to a value that collides), Tailscale will treat both advertisements as routes for the same IPv6 prefix and pick one as primary. Resolve by changing one of the site IDs in /opt/autocore/config/config.ini under [bridge] site_id =, then restart autocore_server.

“After enabling the bridge, the embedded computer can’t reach the Internet.” The ip_forward sysctl we install does not change the machine’s own routing; only its willingness to forward packets it receives. Internet trouble after enabling is coincidence — likely a DHCP renewal or unrelated NetworkManager event. Check with ping 8.8.8.8.

Part 2: For Developers and Users

This part is for everyone who uses a Network Bridge but didn’t set it up. If you don’t have an account on login.tailscale.com with admin access, you’re in this part.

The pattern is: your admin has put a bridge in place, generated a short text block, and sent it to you. You have to do two things, once, on your laptop:

Install Tailscale and sign in to the company tailnet.
Paste the text block into your laptop’s hosts file.

After that, you use the friendly names (panel-pc-3833, ni-rack-3833, etc.) just like any other hostname.

2.1 What you need from your admin

Before you start, message your admin and confirm:

You have an invite to the company Tailscale tailnet. This will come as an email from Tailscale. If you’ve never accepted it, do that now.
They have a “hosts snippet” for this project. This is the block of text generated from the AutoCore Console’s Network Bridge panel. It looks like this:
```
# autocore Network Bridge — site_id 3833 (adc-sn-3833) — 4via6 prefix fd7a:115c:a1e0:b1a:0:ef9::/96
fd7a:115c:a1e0:b1a:0:ef9:c0a8:7f05	ni-rack-3833
fd7a:115c:a1e0:b1a:0:ef9:c0a8:7f64	panel-pc-3833
```
If you don’t have one, ask. Tell them which project you’re working on so they generate it from the right machine.
The route is approved on the embedded computer. This is the admin’s job; you can’t verify it yourself. If anything below doesn’t work, the most likely cause is “the admin forgot to approve the route in the Tailscale admin console.” Ask them to check.

2.2 Install Tailscale on your laptop

You only do this once.

Windows

Go to tailscale.com/download/windows and download the installer.
Run the installer. Click through the defaults.
A small Tailscale icon will appear in your system tray (bottom right of the screen, near the clock — you may need to click the “show hidden icons” arrow).
Right-click the icon, choose Log in, and follow the link to sign in. Use your company email account — your admin should have already added you to the tailnet.

macOS

Install from the Mac App Store: search for Tailscale.
Open the Tailscale app. A small icon appears in the menu bar at the top of the screen.
Click the icon, choose Log in, and sign in.

Linux

Follow the official instructions at tailscale.com/download/linux for your distribution. For Ubuntu, that’s:
```
curl -fsSL https://tailscale.com/install.sh | sh
```
Sign in:
```
sudo tailscale up
```
This prints a URL. Open it in a browser and sign in with your company account.

Verify Tailscale is running

After signing in, on Linux or macOS open a terminal and run:

tailscale status

On Windows, open PowerShell or Command Prompt and run the same command.

You should see your laptop’s name at the top, followed by a list of other devices in the tailnet, including the embedded computer (e.g. adc-sn-3833). If you see the embedded computer in the list, you’re ready for the next step.

If the list is empty or you see Logged out, repeat the sign-in step above. If you don’t see the embedded computer specifically, ask your admin to confirm you’re on the right tailnet.

2.3 Add the hosts snippet to your laptop

The hosts file on your laptop is a small text file that maps hostnames (like panel-pc-3833) to IP addresses. When you type a hostname in your browser, your laptop checks this file first; if it finds a match, it uses that IP and skips DNS entirely. That’s how the friendly names from the snippet will work without your admin having to register them anywhere.

The file is in different places on each OS. Editing it requires administrator rights on your laptop (because it affects all users).

Linux / macOS

Open a terminal.
Open the file with sudo (you will be prompted for your laptop password):
```
sudo nano /etc/hosts
```
You can use any other text editor if you prefer — sudo vim /etc/hosts, etc. — but nano is the simplest if you don’t have a preference.
Use the arrow keys to move to the end of the file. Press Enter to start a new line.
Paste the snippet (in nano, paste is usually Ctrl+Shift+V on Linux or Cmd+V on macOS; in other terminals it may differ).
Save and exit:
- In nano: Ctrl+O, Enter, then Ctrl+X.
- In vim: Esc, then :wq, then Enter.
Verify by running:
```
getent hosts panel-pc-3833
```
(Replace panel-pc-3833 with one of the names from your snippet.) You should see one line of output: the IPv6 address followed by the name. If you get no output, the paste didn’t take or you saved the wrong file.

Windows

Press Windows key, type notepad, right-click the Notepad app, and choose Run as administrator. (Notepad must be opened this way; opening it normally won’t let you save changes to the hosts file.)
In Notepad, choose File → Open.
In the file path field at the bottom, type:
```
C:\Windows\System32\drivers\etc\hosts
```
and press Enter. (If Notepad shows “no files found,” change the file-type dropdown from “Text Documents (*.txt)” to All Files.)
Move to the end of the file and press Enter to add a new line.
Paste the snippet (Ctrl+V).
Save with File → Save (Ctrl+S).
Verify by opening PowerShell or Command Prompt and running:
```
ping -6 panel-pc-3833
```
(Use one of the names from your snippet.) If your laptop can find the name, the ping will resolve and either succeed or time out — either result means the name resolved. If you get “Ping request could not find host…”, the paste didn’t take.

2.4 How to use the names

Once the snippet is in place, you can use the friendly names anywhere you’d normally type an address or hostname:

In a web browser:

http://panel-pc-3833/

Just like any other URL. You do not need square brackets when you use the friendly name — the brackets are only needed for raw IPv6 addresses.

If you ever need to use the raw IPv6 address (without a name) in a browser, you do need brackets:

http://[fd7a:115c:a1e0:b1a:0:ef9:c0a8:7f64]/

For pings (use the -6 flag on Windows; on Linux/macOS, plain ping works for both):

ping panel-pc-3833           # Linux, macOS
ping -6 panel-pc-3833        # Windows

In vendor tools (NI MAX, robot teach pendant, etc.): type the friendly name wherever the tool asks for an IP address or hostname. Most modern tools resolve hostnames automatically. Older tools that demand a raw IP can be given the IPv6 address from the snippet directly — but check whether the tool actually understands IPv6 first. Many older industrial tools do not, in which case the friendly name approach above won’t help either; you’ll need to use SSH port forwarding instead (see Older Tools That Only Speak IPv4 below).

In code: most networking libraries handle both name resolution and IPv6 transparently. requests.get("http://panel-pc-3833/api") in Python or fetch("http://panel-pc-3833/api") in JavaScript will both work as you’d expect.

2.5 Common problems

“I can’t reach any of the names”

Most common cause: Tailscale isn’t running on your laptop, or your laptop disconnected from the tailnet and didn’t reconnect.

Check the Tailscale icon in your system tray / menu bar — it should look “active” (the icon varies by version, but a struck-out or grey icon is bad).
Run tailscale status in a terminal. The first line should not say Logged out.
Verify you can reach the embedded computer itself (not just the bridged devices):
```
ping adc-sn-3833
```
If that fails, the problem is your tailnet connection, not the bridge. Sign back in to Tailscale.

“I can reach the embedded computer, but not the bridged devices”

This means Tailscale is working, but the bridge isn’t.

Ask your admin: “is the route approved for adc-sn-NNNN?” If they say no or aren’t sure, they need to revisit Part 1, section 1.5.
Check you actually pasted the snippet into the hosts file. Try:
```
getent hosts panel-pc-3833      # Linux, macOS
ping -6 -n 1 panel-pc-3833      # Windows
```
No output / “could not find host” → snippet not in your hosts file. Re-do section 2.3.
Check the device is actually online. The admin can use the Scan button in the Network Bridge panel to confirm; if it doesn’t appear in their scan, no remote access will work either.

“It worked yesterday and now it doesn’t”

Most likely one of:

Your laptop’s Tailscale signed out (laptop suspended for a long time, lost auth token). Sign back in.
The embedded computer rebooted but Tailscale didn’t auto-start. Ask your admin.
The customer’s local network changed and the embedded computer lost its IP. Ask your admin to confirm tailscale status on the embedded computer.
Someone disabled the bridge from the AutoCore Console. Ask your admin.

“I’m getting some weird IPv6 error from a tool I’m using”

Some older networking tools (especially Windows-side industrial software) don’t understand IPv6. If a tool refuses to connect to one of the friendly names but everything else works:

Try entering the raw IPv6 address (with [brackets] for URLs) directly. If the tool accepts that, it just didn’t like the friendly name; report this to the tool’s vendor.
If the tool refuses the IPv6 address too, it can’t speak IPv6. See Older Tools That Only Speak IPv4 below.

2.6 Older tools that only speak IPv4

A small number of industrial tools — usually old proprietary Windows software — simply cannot connect to anything but an IPv4 address. For those, the Network Bridge feature as documented above won’t help, and you’ll need to use SSH port forwarding instead. This is the “PuTTY trick” you may have heard about.

The short version:

SSH into the embedded computer (using its friendly Tailscale name, e.g. ssh user@adc-sn-3833).
Tell SSH to forward a port on your laptop to the target device’s IPv4 + port on the embedded computer’s side.
Point the old tool at localhost:<the-forwarded-port>.

A worked example, talking to a panel PC’s web UI:

ssh -L 8080:192.168.127.100:80 user@adc-sn-3833

Now you can open http://localhost:8080/ in your browser and you’ll be talking to the panel PC’s port 80 over the SSH tunnel. Leave the SSH connection open as long as you need the tunnel.

For permanent setups, use a PuTTY saved session with the Connection → SSH → Tunnels panel filled in similarly. If you need help setting that up, ask your admin or one of the more experienced developers on the team — port forwarding is a slightly deeper topic than this manual covers.

2.7 When to escalate

Send a message to your admin (or to ADC support) when:

tailscale status shows you signed in to a different tailnet than your colleagues are on. Your admin needs to fix tailnet membership.
You followed every step here, the route is approved (your admin confirmed), and you still can’t reach any device by name or by raw IPv6.
You can reach some devices but not others, and the admin’s scan shows everything is fine on their end.
You see your laptop’s Tailscale list contains the embedded computer in red or with an “offline” tag, even though you know the embedded computer is on.

Include in your message:

The friendly name (or IPv6) you’re trying to reach.
The exact command or URL you tried.
The exact error you got back (a screenshot is fine).
The output of tailscale status from your laptop.

That’s everything ADC support or your admin needs to diagnose 90% of issues.

Glossary

This glossary defines every special term used in this appendix. If you have a moment, skim it once even if you think you know the terms — the definitions here are tied specifically to how AutoCore uses each concept.

4via6 — A specific Tailscale feature for routing IPv4 subnets through an IPv6 prefix. We use it because multiple ADC machines deployed in the field share the same 192.168.127.x IPv4 range internally; 4via6 lets each machine appear under its own unique IPv6 prefix from the laptop’s point of view, so traffic to “Project A’s panel PC” and “Project B’s panel PC” doesn’t collide. Pronounced “four via six.”

ADC machine — An embedded computer running autocore-server that ADC has built and shipped. Identified by a serial number; hostnamed adc-sn-<serial>.

Admin console (Tailscale) — The web UI at login.tailscale.com where tailnet admins manage machines, users, ACLs, and routes. Distinct from the AutoCore Console; they have nothing to do with each other beyond both being “consoles.”

AutoCore Console — The web UI hosted by an ADC machine at http://<machine-name>/console. It contains the Network Bridge tab this appendix is about, alongside other admin tools.

CIDR — Address-and-prefix notation, like 192.168.127.0/24. The /24 means “the first 24 bits of the address identify the network; the last 8 bits identify a specific host.” 192.168.127.0/24 is a range of 256 addresses, 192.168.127.0 through 192.168.127.255.

hosts file — A small text file on every laptop and server that manually maps hostnames to IP addresses. When you type a hostname, your operating system checks the hosts file before asking DNS, so hosts-file entries always win. Lives at /etc/hosts on Linux/macOS and C:\Windows\System32\drivers\etc\hosts on Windows.

Hosts snippet — The block of text the AutoCore Console produces under “Hosts-file snippet.” Pasted into a laptop’s hosts file by the developer, it maps friendly names (like panel-pc-3833) to the IPv6 addresses Tailscale 4via6 expects.

IPv4 — The original Internet address format. Looks like four numbers separated by dots: 192.168.127.5. Most things still use it on local networks.

IPv6 — The newer Internet address format. Eight groups of hex digits separated by colons: fd7a:115c:a1e0:b1a:0:ef9:c0a8:7f05. Most modern operating systems and tools handle it transparently, but a few older tools don’t. In URLs, IPv6 addresses must be wrapped in [square brackets].

Process network — The isolated LAN attached to the embedded computer’s second network adapter, hosting the field devices (NI rack, panel PC, robot, PLC, etc.). Typically 192.168.127.0/24.

Route approval — In Tailscale, a node advertising a subnet route is only a request — the route doesn’t actually carry traffic until a tailnet admin clicks Approve in the Tailscale admin console. This two-step model exists so a misconfigured (or hostile) node can’t silently start announcing routes for sensitive networks.

Site ID — A 16-bit integer (1–65535) that identifies one ADC machine’s process-network space distinct from any other ADC machine’s. Derived from the machine’s serial number. Appears inside the IPv6 addresses generated by 4via6 — e.g. the ef9 in fd7a:115c:a1e0:b1a:0:ef9:c0a8:7f05 is hex for site ID 3833.

Subnet — A range of IP addresses, usually contiguous. The process network 192.168.127.0/24 is a subnet; so is your home WiFi (typically 192.168.0.0/24 or similar).

Subnet routing — A Tailscale feature where one machine in the tailnet acts as a router into a network that other tailnet members can’t directly see. Without 4via6 it’s plain IPv4 routing; with 4via6 it’s IPv4-via-IPv6 routing. This is the core mechanism behind the Network Bridge feature.

Tailnet — A private network of devices that have all signed in with the same Tailscale credentials. Your company likely has one tailnet; ADC has its own. Within a tailnet, every member can usually reach every other member by name.

Tailscale — Commercial software (with a generous free tier) that builds a private overlay network between authenticated devices. The underlying technology is WireGuard plus some clever NAT-traversal and identity infrastructure. We use it because it works reliably across home networks, cellular hotspots, hotel WiFi, and corporate firewalls, none of which are easy to penetrate with a plain VPN.

Keyboard shortcuts