Lodestar L2TP / Coming soon
A public IPv4 over the connection you already use.
Lodestar L2TP is being built for people who need a stable public address without replacing their broadband or mobile connection. The tunnel brings traffic to Lodestar, applies the selected speed profile and sends it to the public Internet using the address reserved for that account.
It cannot be ordered yet. The operational pilot is not the public service. Production addressing, payment acceptance, device testing, recovery procedures and customer terms must be completed before orders open.
- Planned tiers
- 500/500 at £3 and 1000/1000 at £4 per month
- Address
- One public IPv4 reserved to each active account
- Usage
- Planned without a data allowance or usage-based throttle; final terms and the selected rate ceiling still apply
- Connection
- One active tunnel across the available protocol choices
- Reviewed
- 20 September 2026
The planned service
The tunnel changes your Internet exit, not your access line.
Your existing provider still carries the connection to Lodestar. The tunnel cannot make that connection faster, repair poor Wi-Fi or remove limits imposed by the access network. It supplies a different routed path and a public IPv4 associated with the Lodestar account.
| Plan | Intended monthly price | Configured ceiling | Data volume | What the figure does not promise |
|---|---|---|---|---|
| 500/500 | £3 | Up to 500 Mb/s upload and 500 Mb/s download | Planned without an allowance or usage-based throttle, subject to final terms | A minimum speed, dedicated 500 Mb/s capacity or 500 Mb/s on every device and access network |
| 1000/1000 | £4 | Up to 1000 Mb/s upload and 1000 Mb/s download | Planned without an allowance or usage-based throttle, subject to final terms | A minimum speed, dedicated gigabit capacity or symmetric gigabit performance on every tunnel mode |
These are intended customer prices. Final pre-contract information will confirm tax treatment, mandatory charges, normally available speeds and the complete commercial terms before an order can be placed.
Unlimited refers to quantity
The product is planned without a monthly data allowance, top-up or usage-based throttle. That position will be set out in the final customer terms before ordering opens. The purchased rate ceiling, shared gateway capacity, the underlying connection and normal network conditions still determine how quickly traffic can move.
A ceiling is not reserved bandwidth
The plan rate is the maximum profile applied to an account in each direction. It does not reserve that amount of physical uplink or processing capacity and it is not a promise that every individual flow will reach the ceiling.
End-to-end path
The customer starts the tunnel. Lodestar terminates and routes it.
The public service will use a shared endpoint. After a website account has been created and its email address verified, paid provisioning creates the service subscription, reserves its address and issues separate tunnel credentials. It does not create a permanent tunnel; the customer's router, phone or computer establishes the connection when needed.
- Customer device or routerCreates the selected L2TP or IPsec session and sends customer packets into it.
- Existing Internet connectionCarries the outer tunnel through the access provider and any NAT or CGNAT in the path.
- Lodestar tunnel gatewayAuthenticates the account and terminates the tunnel. The production design also requires session, address, isolation and rate enforcement.
- Public InternetReceives routed traffic using the public IPv4 reserved to the active account.
| Stage | What happens | Boundary |
|---|---|---|
| Registration | The customer creates a website account and verifies the email address. | A website account alone does not enable a tunnel. |
| Payment validation | The planned worker checks the current paid subscription independently of the browser returning from hosted checkout. | A redirect or webhook by itself is not treated as entitlement. |
| Provisioning | The system reserves one address, creates separate tunnel credentials and records the selected speed profile. | Portal credentials and tunnel credentials are different. |
| Admission | The gateway authenticates the session, checks service state and prevents two active delivery paths from claiming one account address. | Changing protocol may require a full disconnect before reconnection. |
| Forwarding | The production design requires routing, source validation, subscriber isolation and the upload/download ceilings on the active session. Those controls still need deployment acceptance together. | Control and accounting records do not carry the customer's application payload. |
| Accounting | Session start, interim state, stop events and byte counters support operations and entitlement handling. | Accounting is not a claim of content inspection or a published data-retention period. |
| Disconnect | The session route is withdrawn while the address remains associated with the account under the current candidate design. | Stale-session recovery is deliberately conservative to avoid assigning one address twice. |
Addressing and reachability
One routed IPv4, not another shared CGNAT address.
The planned model associates one public IPv4 with one account and routes it through the authorised active tunnel. The address remains with the account through ordinary reconnections. It is not sold as a customer subnet, a BGP service or a layer-2 Ethernet circuit.
Using the address on one device or a whole LAN
A tunnel endpoint can use the assigned address directly. A compatible router can instead translate traffic from its private LAN onto that address and apply its own inbound port-forwarding or static-NAT rules. Those LAN rules remain part of the customer's router configuration. Lodestar is not currently building a hosted port-forwarding control panel.
Inbound connections have several dependencies
Inbound traffic must reach the assigned address, the account must have an authorised active tunnel, and the customer's firewall, listener and any router NAT must permit the connection. The final port policy and hosting permissions still need approved terms and acceptance testing. A public IPv4 does not mean that every port or application is guaranteed to work.
Address retention is not ownership
The current candidate retains the reservation through renewal, suspension and ordinary reconnection. Cancellation and eventual address recycling still require an approved operator process. The address remains network space supplied as part of the service; it does not become the customer's permanent property.
Not yet promised
IPv6: no customer IPv6 service or delegated prefix has been accepted for launch.
DNS: resolver supply, customer resolver choice and effective routing still need documentation and device testing.
Reverse DNS: customer-editable PTR records and delegation are undecided.
Mail and server hosting: port policy, hosting permission and abuse handling require the final customer terms.
Tunnel security
L2TP, L2TP/IPsec and IKEv2 are not interchangeable names.
Plain L2TP provides tunnelling but no meaningful packet confidentiality or integrity. L2TP/IPsec adds IPsec protection around L2TP and PPP. Native IKEv2/IPsec carries IP through IPsec without adding the L2TP and PPP layers.
| Mode | Packet protection | Authentication | Important limit |
|---|---|---|---|
| Plain L2TP | No tunnel encryption, per-packet integrity or anti-replay protection | Separate tunnel username and password | Suitable only where the customer knowingly opts in and applications provide their own protection, such as HTTPS |
| L2TP/IPsec | IPsec ESP can provide encryption, integrity and replay protection between the client and Lodestar gateway | Tunnel credentials plus the IPsec authentication material required by the selected profile | More encapsulation, legacy-client variation and device-specific cipher or acceleration limits |
| Native IKEv2/IPsec | IPsec protection without the L2TP and PPP layers | Tunnel credentials with a verified server certificate in the prepared profiles | Still depends on IPsec support, UDP reachability, NAT-T, MTU handling and correct server-identity validation |
Plain L2TP is not a privacy VPN
L2TP tunnel authentication does not encrypt the carried packets. Someone able to observe or interfere with the path may still see or alter unprotected traffic. HTTPS and other application encryption remain necessary, whether or not a tunnel is used.
IPsec protects only as far as the gateway
IPsec can protect traffic between the customer's device and Lodestar. Once traffic leaves the Lodestar gateway for its destination, application end-to-end protection still matters. TLS inside IPsec is not wasteful duplication: it continues beyond the tunnel endpoint.
| Mode | Normally visible outside the tunnel | Clarification |
|---|---|---|
| Plain L2TP | UDP destination 1701 | Source ports may be ephemeral. This traffic is not encrypted merely because it is L2TP. |
| L2TP/IPsec without NAT-T | IKE on UDP 500, followed by ESP as IP protocol 50 | ESP is an IP protocol, not port 50. UDP 1701 is inside IPsec when correctly protected. |
| L2TP/IPsec with NAT-T | Usually UDP 500 followed by IKE and ESP-in-UDP on UDP 4500 | NAT-T gives translated clients a port-based outer flow. It does not guarantee that every firewall or CGNAT will pass it. |
| Native IKEv2/IPsec | UDP 500 and/or UDP 4500, with ESP carried natively or in UDP | There is no L2TP UDP 1701 layer in a native IKEv2 data path. |
Where performance and compatibility can change
Encryption adds useful protection and real engineering limits.
IPsec is not one fixed performance mode. Cipher support, packet size, client CPU, hardware acceleration, operating-system networking, NAT behaviour and the gateway all affect the result. A plan labelled 1000/1000 cannot make every encrypted client run at one gigabit.
NAT and CGNAT
NAT-T detects address translation and normally moves IKE and ESP into UDP 4500 so a NAT can track the flow. Several clients can work behind one NAT because their translated UDP ports differ, but old VPN passthrough features, overlapping policies, UDP timeouts, state loss and carrier filtering can still break setup or rekeying. CGNAT does not automatically block an outbound tunnel, but it adds another network Lodestar cannot control.
MTU, MSS and fragmentation
L2TP/IPsec adds outer IP, IPsec ESP, optional NAT-T UDP, L2TP, PPP, padding and authentication data. The exact overhead depends on the protocol and algorithms. The pilot uses a 1400-byte tunnel MTU, but no single value works on every access path. Incorrect path-MTU discovery can create stalls. TCP MSS adjustment helps TCP only; UDP and other traffic still need a correct packet-size path.
Client and gateway processing
Encryption and authentication consume CPU. Hardware acceleration may help only for particular algorithms and packet paths. In a short synthetic-client comparison, AES-GCM measured about 965 Mb/s upload and 960 Mb/s download when tested separately. CBC measured 574 and 594 Mb/s upload in the before-and-after controls, and 637 Mb/s in the completed download comparison. With upload and download running together, GCM measured about 515 Mb/s up and 598 Mb/s down.
Those figures compare one controlled lab path. They do not qualify simultaneous 1000/1000 service, customer routers, phones or every native L2TP/IPsec client. GCM support and hardware acceleration vary by platform, and the last planned CBC download control was not reached. The test changed no public-service configuration.
Reconnect, roaming and rekeying
A tunnel may need to be rebuilt after a router restart, phone sleep, access-network change, NAT mapping loss or IPsec rekey. An isolated reconnect test required a delayed retry before the same endpoints could reconnect. That observation is not a universal timer. In the latest controlled IPsec run, key renewal negotiated and no tunnel break was observed before cleanup, but the test harness rejected the expected overlap between old and new security associations. Post-renewal identity and traffic acceptance therefore remain inconclusive. The launch matrix still needs repeated rekey, reconnect, sleep/wake, roaming and stale-accounting recovery on physical devices.
No TCP fallback
The prepared service does not include a tunnel fallback on TCP 443. Networks that block UDP 1701, 500 or 4500, or mishandle ESP and NAT-T, can prevent a connection even when ordinary web browsing works.
IKEv2 fragmentation is not data fragmentation
IKEv2 fragmentation can help large IKE control messages such as certificate exchanges. It does not fix an oversized ESP data packet. Data-path MTU and fragmentation still have to be handled separately.
Capacity and compatibility
253 lab sessions do not equal 253 dedicated gigabit circuits.
An isolated laboratory test used a pool of 253 test addresses, authenticated 253 simultaneous plain-L2TP sessions and checked unique address allocation and routing. The final public address allocation and routing are still outstanding. The test did not run 253 encrypted customers at sustained traffic and it did not qualify a 10 Gb/s retail service.
The server uplink is unmetered at 10 Gb/s, but it is shared. Customer tunnel traffic and onward Internet traffic both cross that path, alongside protocol overhead and other services. If all 253 accounts were equally busy, 10 Gb/s is roughly 39.5 Mb/s of combined traffic per account before overhead. Real use will not be perfectly equal, but the calculation shows why the plan ceiling is not a dedicated reservation.
| Hypothetical load | Customer download | Customer upload | Approximate demand in each physical uplink direction before overhead |
|---|---|---|---|
| 253 accounts at 500/500 simultaneously | 126.5 Gb/s | 126.5 Gb/s | 253 Gb/s |
| 253 accounts at 1000/1000 simultaneously | 253 Gb/s | 253 Gb/s | 506 Gb/s |
This is a boundary calculation, not a forecast of customer demand. It demonstrates that all customers cannot use both plan ceilings continuously at the same time.
Device acceptance is still open
Setup material has been prepared for Apple IKEv2, Android strongSwan and selected router platforms. Passing a profile-structure test is not the same as physical-device acceptance. Router model, firmware, IPsec algorithm support, hardware acceleration and behaviour behind NAT all need to be recorded in the launch compatibility matrix.
There is still one main failure domain
The service currently depends on one gateway VM, its physical host and shared connectivity. A larger VM configuration supported the session-scale lab, but geographic failover and a contractual availability target have not been established. No service-level agreement or automatic service credit is offered by this coming-soon page.
Readiness
What exists, what is being completed and what we do not claim.
The public page will stay marked coming soon until the production address block, routing, billing, device acceptance and recovery procedures have been tested together.
Operational pilot
A small working pilot has been used for connection and throughput testing. It is not a launched retail service and it does not demonstrate public-scale capacity.
Built and locally verified
Account registration, email verification and recovery, payment-gated provisioning logic, address reservations, one-session admission, rate profiles, accounting integration, setup material and deployment candidates exist.
Session-scale laboratory evidence
An isolated lab established 253 authenticated plain-L2TP sessions with unique address allocation and routing checks. Smaller tests exercised real IKEv2 and L2TP/IPsec authentication and traffic.
Still required before ordering
The real address allocation and delivery method, controlled payment-provider validation, production deployment acceptance, physical-device testing, reconnect qualification, backups, restoration, support arrangements and approved customer policies remain open.
Not established
We do not claim 253 encrypted customers under sustained load, symmetric gigabit on every device, every port open, universal NAT compatibility, geographic failover, a minimum speed or a public availability guarantee.
Accounting is necessary, but it is not the same as inspecting content
The candidate uses account state, authentication results, the assigned address, session timing and byte counters to admit service and operate it safely. It is not being presented as anonymous or retention-free. The final privacy notice must define the data kept, why it is used and how long it remains. A general “no logs” claim would be inaccurate.
Standards and platform guidance
Technical references behind this page.
These references define the protocols and important implementation boundaries. Their inclusion is not third-party certification of Lodestar or a promise that every optional feature is enabled.
RFC 2661Layer Two Tunneling Protocol version 2, including UDP transport and the limits of L2TP security.
RFC 3193Securing L2TP using IPsec, including packet protection and MTU considerations.
RFC 4301The IPsec security architecture.
RFC 7296IKEv2 negotiation and the creation of IPsec security associations.
RFC 3947NAT detection and negotiation for IKE.
RFC 3948UDP encapsulation of IPsec ESP through NAT, including multiple-client considerations.
RFC 3715IPsec and NAT compatibility requirements.
RFC 7383Fragmentation of IKEv2 control messages, distinct from data-path fragmentation.
RFC 4459MTU and fragmentation considerations when tunnelling network packets.
strongSwan forwarding guidancePath MTU and TCP MSS behaviour for forwarded IPsec traffic.
Linux XFRM offloadWhy IPsec processing cost and hardware support can materially affect throughput.
Apple VPN overviewCurrent Apple deployment support and configuration boundaries for IKEv2 and L2TP/IPsec.
Microsoft VPN protocol guidanceCurrent server-side guidance and the legacy position of L2TP for new Windows RRAS deployments.
Android VPN documentationAndroid's platform distinction between current VPN APIs and legacy built-in VPN clients.
Have a router or access network you want included in acceptance testing? Email hello@lodestarnetworks.co.uk with the exact model, firmware and connection type.