Public IP and L2TP

Follow a public IP tunnel

Keep the Internet connection you already have and add a static public IPv4 through Lodestar.

The outward journey

Your router sends selected traffic into a tunnel. Your existing provider carries the outer packets to our gateway. Lodestar authenticates the service, applies the plan and routes traffic using the assigned public IPv4. From the Internet, replies return towards that address through AS218388.

Two layers of travel

The outer packet gets the tunnel across your existing connection. The inner packet carries your application traffic. This is why the company supplying your physical connection can be different from the network supplying your public address. The selected method determines how the tunnel is protected.

Different ways to tunnel

Our public IP service offers several connection methods, each with a different setup and protection model.

L2TP and IKEv2

L2TP carries PPP sessions. Plain L2TP has no built-in encryption; L2TP/IPsec adds IPsec protection around it. Native IKEv2 negotiates an IPsec tunnel directly, using a different session path. Compatible equipment and the correct profile matter for each method.

WireGuard and device choice

WireGuard uses a key-based interface and peer model, with rules selecting traffic for the tunnel. WireGuard, IKEv2 and compatible L2TP/IPsec are available on both plans, with one active method per subscription. Router support, firmware, NAT and UDP filtering help determine the right choice. Keep personal keys private, and continue using application encryption such as HTTPS.

The gateway behind the service

Our tunnel gateway joins customer sessions, account policy and public IPv4 routing in one dedicated service environment.

Receiving the connection

Accel-PPP handles L2TP sessions, with separate concentrators for IPsec protected and plain transport. strongSwan provides the IPsec functions for L2TP/IPsec and native IKEv2. WireGuard supplies the key-based alternative. Each method brings customer traffic into the gateway using its own session model.

Applying the account policy

FreeRADIUS provides authentication and session policy. Account instructions set the speed profile, while duplicate concurrent L2TP sessions are blocked. PPP echo checks help detect a connection that has stopped responding. Reduced packet sizes leave room for the extra headers added by the tunnel.

Delivering the public address

Routes from the core deliver individual public IPv4 addresses to the gateway. The gateway then associates the address with the correct customer session. This is how incoming traffic can find the tunnel while the wider Internet sees a stable address from our announced range.

Looking after the lifecycle

Background services track connection quality and tidy up superseded IKEv2 reconnect sessions. An independent expiry timer checks service entitlement alongside the billing worker. These small pieces of engineering matter: a service needs to handle reconnection, account changes and expiry as carefully as its first successful login.

From order to active service

The account, payment, address and gateway have to stay in step throughout a public IP subscription.

From checkout to connection

Our portal reserves capacity before checkout. A separate worker checks the payment-provider record and grants the service entitlement. It handles duplicate or delayed messages, then reconciles the required service state with the gateway through a restricted provisioning path.

Keeping the lifecycle together

RADIUS connects the account to authentication and session policy. The gateway checks expiry independently. Inventory, connection quality, alerts and accounting help me track service after activation. I have built these surrounding tools because the customer experience depends on more than the first successful login. Account changes, reconnection, renewal and recovery all need a clear path.

Speed, packet size and performance

A fast connection depends on the whole journey, from the customer’s router to the application at the far end.

Our public IP plans

L2TP 500 is £3.50 per month, with an up to 500 Mb/s profile in each direction. L2TP 1000 is £4.50 per month, with an up to 1000 Mb/s profile. Both include unmetered data and one static public IPv4. These are service speed ceilings.

Where a transfer can slow down

Your access line, Wi-Fi, Ethernet ports, router processor and encryption can all affect throughput. So can congestion and the remote server. A faster tunnel profile cannot make a slower physical line faster. Latency and packet loss also matter, especially for interactive applications.

Why packet size matters

MTU means Maximum Transmission Unit: the packet-size limit for a link. A tunnel adds headers around the original packet, so it needs room for them. An unsuitable size can cause pages to partly load or transfers to stall even when small requests still work.

Measuring what you experience

A useful check includes upload, download, latency, loss and reconnection. Record whether the device is wired or wireless and compare different times of day. Looking at several measurements gives a better picture than a single speed-test result and helps identify which part of the path needs attention.

What a public IPv4 enables

A stable public address gives your own equipment a consistent place on the Internet, even when your access provider uses shared addressing.

A way through shared NAT

Some access providers place households behind carrier-grade NAT, sharing public addresses between customers. That can make incoming connections difficult. Our tunnel gives traffic another entry path through Lodestar, while your existing broadband or mobile connection continues to carry the tunnel itself.

Useful for your own projects

A public IPv4 can support remote access to your equipment, a home lab or permitted self-hosted services. If a router shares the address across several devices, its port-forwarding rules decide where an incoming connection goes. The public address is the destination; those rules choose the local device.

Open the services you need

Your firewall should permit the intended service and close unnecessary access. Applications still need updates and suitable authentication. Tunnel encryption protects the connection to the gateway, while the server at the end of the route remains responsible for its own security.

Understand the dependencies

Remote access relies on the physical line, router, tunnel and application all working. A reboot or outage can interrupt reachability. Our current public IP service has no availability SLA. For an essential remote site, plan a recovery method that suits the importance of the equipment you are reaching.