Mesh VPN vs. Consumer VPN vs. Exit Node

What distinguishes a mesh VPN, consumer VPN, and exit node?

A consumer VPN supplies a provider-operated route to public egress, a mesh VPN connects authorized nodes and resources, and an exit node is a separately enabled route through one selected mesh device in the named implementations compared here.

The general virtual private network baseline is narrower than any product label. The National Institute of Standards and Technology defines a virtual private network as a virtual network “built on top of existing physical networks” that can provide secure communications between networks or nodes. That definition establishes a network mechanism. It does not establish anonymity, a no-logging result, a specific egress operator, a DNS resolver, or one universal topology.

The three rows on this page use named, source-dated implementations. The Mullvad VPN application, a Tailscale tailnet, and Tailscale exit nodes are described from provider materials captured on October 6, 2026. Each statement remains bounded to those dated materials.

Access target asks what the user or device joins. Routed traffic asks which packets the documented configuration carries. Authorization asks who or what enables the path. Egress asks where traffic reaches the public internet and whose address a destination observes. DNS, account identifiers, and retained records remain separate questions because one answer cannot fill another.

What does the consumer VPN record establish?

Mullvad materials captured on October 6, 2026, state that the Mullvad VPN application connects a numbered account to selected Mullvad servers, reports entry and exit addresses, uses Mullvad DNS by default, and documents specific account and operational records.

For traffic and egress, Mullvad's materials captured on October 6, 2026, describe the application route and its documented multihop option. The provider says multihop traffic is routed “from one WireGuard server to another.” The application lets a user select a country, city, or server, and its connection view reports the server entry address, port and transport protocol, plus the server exit address. Mullvad states that its listed physical VPN servers are owned or dedicated rentals and run from memory without persistent storage. These statements describe the provider's documented application and server fleet, not every third-party WireGuard configuration.

For DNS, Mullvad states that its application redirects requests to Mullvad's resolver by default: “DNS requests get rerouted” to Mullvad's non-logging resolver. The provider materials state an exception for separately configured DNS over HTTPS or DNS over TLS behavior. A default resolver path is not proof that every possible client configuration follows it.

For identity and records, Mullvad describes a random account number rather than a username, password, or email address. Its policy calls that number “the only identifier a person needs” to use an account. The same dated materials describe account expiry, payment records, WireGuard public-key and tunnel-address data where applicable, aggregate operational measures, short-lived website logs, and support records. Mullvad says it logs nothing that can be connected to a numbered account's activity, including no traffic, DNS requests, connection timing, IP addresses, or per-user bandwidth; its policy states exceptions for total simultaneous connections and payment information. Those are provider statements captured on October 6, 2026, not traffic-audit findings or a universal consumer-VPN rule.

What does the mesh VPN record establish?

Tailscale materials captured on October 6, 2026, state that Tailscale enrolls devices into a tailnet, applies device and policy controls, supports separately approved subnet routes, and attempts direct connections before relay fallbacks.

Enrollment and authorization are distinct in Tailscale's materials captured on October 6, 2026. A device can authenticate with the account used to create the tailnet or with an authentication key. If device approval is enabled, Tailscale states that a device awaiting approval “cannot send or receive traffic” on the tailnet until an administrator approves it. Access-control lists or grants then define which sources may reach which destination devices and ports. The initial default tailnet policy permits communication among tailnet devices until customized, while deny-by-default describes configured rule evaluation rather than every untouched tailnet.

Resource reachability is also separate from enrollment. A subnet-router device can advertise network prefixes, but route approval or auto-approval and access-control permission are different mechanisms. Tailscale states that “route approval controls which routes are injected” while access rules control permitted traffic. A device joining the tailnet does not by itself establish that every private resource or advertised subnet is reachable.

Tailscale says connections begin relayed through a DERP server while the system attempts a direct connection. If direct traversal fails, the system tries a peer relay and can remain on a DERP server. DNS is configurable too: Tailscale documents local device DNS as the default, MagicDNS for tailnet names, and administrator-defined global or restricted nameservers, with an override required to force the defined servers for all queries.

Tailscale also documents account and device data, public keys, addresses, access times, connection metadata, centralized operational events, optional flow logs, and configuration audit logs available for the most recent 90 days. The provider states it cannot access end-to-end-encrypted user-traffic content. Optional flow logging and retention vary by feature, plan, purpose, law, and configuration; no single mesh-VPN retention duration is established.

What does an exit node change?

Tailscale materials captured on October 6, 2026, state that an exit node must advertise the role, receive administrative allowance, and be selected by each client before it carries the documented non-Tailscale traffic to public egress.

An exit node is not implied by membership in the mesh. Tailscale's materials captured on October 6, 2026, describe three separate steps: a device advertises exit-node capability, an Owner, Admin, or Network admin allows it for the tailnet, and each client explicitly selects whether to use it. The provider states, “Every device must explicitly opt in to using an exit node.” Where a customized access policy is present, permission for the internet destination group is another control. Those steps preserve the difference between joining the tailnet and sending public-internet traffic through one tailnet device.

The routed scope has documented boundaries. Tailscale says an exit node captures network traffic that is not already directed to a subnet router or application connector by default, using the IPv4 and IPv6 default routes. Platform-specific split tunneling may narrow that scope. External destinations then observe the exit node's public address instead of the client's local public address. That statement applies to Tailscale exit nodes; it does not define every product using the term exit node.

The DNS path changes with the selected Tailscale exit node. Tailscale states that the client uses the exit node as resolver for all domains by default unless a nameserver is explicitly configured for exit-node use. That is a provider-specific default with a stated configuration exception, not a conclusion about all mesh traffic or all exit-node implementations.

Tailscale documents account, device, and connection metadata for the mesh. It also states that exit-node destination logging is disabled by default, is available for Premium and Enterprise plans, and requires a sales contract to enable. Optional flow logs exclude traffic contents, configuration audit logs are available for 90 days, and general retention depends on purpose and legal requirements. None of those statements proves that a particular destination log was enabled or that every record category shares one retention period.

How do the three implementations compare across the same fields?

The comparison separates access target, routed traffic, authorization, egress, DNS, identifiers, retained records, and source date so no product label supplies a missing value.

Read each line as an evidence ledger that does not order products. The Mullvad VPN, Tailscale tailnet, and Tailscale exit-node materials were captured on October 6, 2026, and every statement remains limited to the named implementation and dated source.

• Consumer VPN — Mullvad VPN, captured October 6, 2026. Access target: a numbered Mullvad account and selected VPN server. Traffic: the documented application route, including an optional multihop path. Authorization: account access and client selection. Egress: a selected Mullvad server whose entry and exit addresses the application reports. DNS: Mullvad resolver by default, subject to the documented exception. Identifiers and records: numbered account, applicable tunnel data, payment and operational records, plus the provider's bounded non-logging statements.
• Mesh VPN — Tailscale, captured October 6, 2026. Access target: an enrolled tailnet device and policy-authorized resources. Traffic: direct, peer-relayed, or DERP paths, plus separately advertised and approved subnet routes. Authorization: authentication, optional device approval, access policy, and route approval. Egress: no public-internet egress is implied by mesh membership alone. DNS: local by default, with MagicDNS and configured nameserver options. Identifiers and records: account, device, key, address, connection, operational, optional flow, and audit records under stated limits.
• Exit node — Tailscale exit nodes, captured October 6, 2026. Access target: the same tailnet plus an allowed and client-selected exit node. Traffic: documented non-Tailscale traffic, excluding stated subnet-router and application-connector paths by default. Authorization: advertisement, administrative allowance, client opt-in, and applicable access policy. Egress: the selected node's public address. DNS: the exit node by default unless specifically configured otherwise. Identifiers and records: Tailscale metadata plus optional, default-off destination logging and the record-specific retention limits.

Why do DNS and TLS answer different visibility questions?

Domain Name System metadata identifies the requested name and source-address context, while Transport Layer Security protects application-channel content but can leave transmitted length observable.

The cited Domain Name System material states that a request includes the queried name and source-address metadata, and that the name can reveal an intended service or communication relationship. The cited encrypted-DNS material states that inspection relying on unsecured DNS transport does not function against DNS over HTTPS because Transport Layer Security protects the query channel. The cited Transport Layer Security material states that application data is visible only to the channel endpoints after establishment, while transmitted length remains observable unless padded.

Those layer facts do not choose a resolver or route for a product. The dated Mullvad VPN, Tailscale tailnet, and Tailscale exit-node materials supply the separate implementation-specific DNS paths above. The cited materials do not establish that encrypted DNS changes public egress, that application-channel encryption hides packet length, or that a VPN label alone identifies which resolver receives a query.

What should be checked before choosing a network boundary?

Check the named implementation's access target, routed scope, authorization steps, public egress, DNS path, required identifiers, retained records, source date, and explicit exceptions before comparing labels.

1. Name the exact product, feature, client, plan, platform, and evidence date instead of relying on the words VPN, mesh, or exit node.
2. Record what the user or device joins, which resources become reachable, and which separate approvals or policy rules control that reachability.
3. Record which traffic enters the route, which traffic is excluded, where public egress occurs, and whose public address a destination observes.
4. Record the resolver path and every stated default or configuration exception without borrowing a DNS answer from another routing mode.
5. Keep account identifiers, device metadata, connection events, flow logs, destination logs, support records, payment records, and retention statements in separate fields.
6. Preserve provider statements as provider statements and leave anonymity, independent verification, and real-world outcomes unestablished unless separate evidence supports them.

This page establishes no comparative privacy, security, speed, or anonymity outcome. It does not establish the behavior of an unnamed consumer VPN, mesh VPN, or exit-node product. It does not verify provider logging statements, prove that a particular connection used the documented path, or show that a destination, resolver, relay, provider, administrator, or device operator observed a specific event.

Configuration can change the answer inside one implementation. A Tailscale tailnet's initial policy, device-approval state, routes, nameservers, exit-node selection, plan, and optional logging settings matter. A Mullvad client configuration, selected server, DNS choice, and payment or support interaction matter. Compare the dated records that match the actual configuration; do not convert the category name into a privacy outcome.

Frequently asked questions

Related research

• The Household Attack SurfaceInventory the identifiers, recovery paths, and records surrounding a network-control decision.
• Outbound Firewalls and Operating-System TelemetrySeparates routing choices from process-level traffic control, observation, and encrypted-channel limits.