DS-Lite blocks inbound IPv4 hosting, not outbound VPN

Translation state follows the side that starts the connection. Follow an outbound request through B4 and AFTR, then see why hosting fails instead.

DS-Lite is a way to give a customer IPv4 connectivity over an access network that only carries IPv6. The home router has no dedicated public IPv4 address of its own, and that single fact convinces people that an IPv4 VPN cannot work from that connection. Outbound, it usually works fine. The connection is translated by the provider, and the far end sees an ordinary IPv4 client. What breaks is the opposite direction: hosting something that expects unsolicited inbound IPv4. The distinction is which end starts the conversation.

Which end starts the connection

A client that initiates a connection creates translation state as it goes. The provider's translator sees the first packet, allocates a mapping, and forwards it. Return traffic matches that mapping because the mapping already exists.

A server that waits for connections has no such state to create. Someone outside has to reach an address and a port that the provider has not agreed to map, which is a different request entirely.

Follow an outbound request

The architecture in RFC 6333 names both ends. The customer-side element is the B4, which encapsulates IPv4 in IPv6. The provider-side element is the AFTR, which performs the address translation and forwards the packet as IPv4.

Client's IPv4 VPN packet
  → Customer B4
  → IPv4 carried over the provider's IPv6 network
  → AFTR address translation
  → IPv4 VPN server

The VPN server receives a normal IPv4 connection from the provider's translated address. It does not need a DS-Lite mode, a special port, or any awareness that the customer's access network is IPv6-only. That is the part people miss: the far end cannot tell.

The client's own configuration is equally ordinary. It needs a working IPv4 path to the server, which the B4 and AFTR provide, and it needs the server's hostname to resolve to an IPv4 address.

Why inbound hosting is the case that fails

Running an IPv4 VPN server at home is the design that collides with shared provider addressing. The provider's translator owns the public address and the mapping table, and it has no reason to create a permanent inbound mapping for one subscriber.

A port-forward rule on the home router cannot configure the AFTR. The rule is real and correct on the local device, and it changes nothing upstream, which is why the symptom looks like a firewall problem that will not go away.

This is also where carrier-grade translation differs from a single public address: even a correct local forward may land on an address that many subscribers share.

Diagnose before changing the access plan

Confirm the provisioned mode first. Native dual stack, DS-Lite and an IPv6-only network using another translation mechanism are three different arrangements, and provider marketing names do not always match the technical one.

Then establish four observations for an outbound failure. Does the client resolve the VPN hostname to an IPv4 destination? Does plain IPv4 connectivity work, rather than a browser request that may have quietly used IPv6? Which transport and port does the client attempt, and do the endpoint logs see that attempt at all? Does the failure happen during the initial exchange, after an idle period, or only on larger transfers?

Those four answers point at filtering, translation-state timeouts, a wrong endpoint or packet-size handling. None of them is established by seeing DS-Lite on the account page.

Read provider changes carefully

An account change can coincide with a working connection while altering several properties at once. Record which property changed, because a new package name is not a technical explanation.

An instruction to enable dual stack is ambiguous until someone confirms what the provider actually provisions. Treating it as a universal requirement for IPv4 VPN clients turns a guess into a policy.

If the real requirement is inbound IPv4 hosting, discuss a supported inbound arrangement, native addressing or another access design with the provider. If the requirement is a laptop reaching a remote server, ask about that exact outbound flow instead. Order of work: name the direction, confirm the provisioned mode, test plain IPv4 and one transport, then change the access plan only if the direction actually requires it.

Mikanda mikatakata