Linux eBPF Sockmap and sk_msg: Socket-to-Socket Redirection for VPN Proxies

High-throughput privacy infrastructure often relies on local proxy daemons, transport wrappers, and sidecars running on the same host or container namespace. In typical VPN deployments, client applications establish connections to a local proxy socket, which decrypts, tags, or wraps traffic before forwarding it to an upstream cryptographic tunnel interface. While this decoupled architecture promotes modularity and granular policy enforcement, conventional Linux networking extracts a heavy performance penalty: every single payload traverses the complete TCP/IP protocol stack twice.

The Linux kernel offers a high-performance alternative through extended Berkeley Packet Filter (eBPF) technologies: BPF_MAP_TYPE_SOCKMAP (or SOCKHASH) combined with BPF_PROG_TYPE_SK_MSG. By operating at the socket interface layer rather than the packet interface layer, eBPF sockmap redirects application data directly from a sender socket receive buffer into a peer socket receive queue. This architectural leap eliminates TCP segmentation, IP route lookups, Netfilter state evaluation, and loopback software interrupt processing.

The Dual-Stack Traversal Tax in Local Proxy Architecture

To appreciate the efficiency gains of eBPF sockmap redirection, consider the lifecycle of an unaccelerated packet flowing through a local VPN ingress proxy:

[ Application Process ]
       | write() / sendmsg()
[ Socket Layer: App TX Queue ]
       v
[ TCP State Machine (Congestion Control, ACKs, Timers) ]
       v
[ IP Layer (Routing Table Lookup, MTU Verification) ]
       v
[ Netfilter / iptables (PREROUTING, FORWARD, POSTROUTING) ]
       v
[ Loopback Interface (dev_queue_xmit, ksoftirqd processing) ]
       v
[ Netfilter / iptables (PREROUTING, INPUT) ]
       v
[ IP Layer (Local Delivery Route) ]
       v
[ TCP State Machine (Sequence Verification, Reassembly) ]
       v
[ Socket Layer: VPN Proxy RX Queue ]
[ VPN Proxy Process ]

When an application transmits a 64 KB payload to 127.0.0.1:1080 (a local SOCKS5 or HTTP CONNECT listener managed by a VPN daemon), the kernel allocates memory buffers (sk_buff), constructs TCP headers, computes checksums, evaluates routing tables, executes Netfilter hook rules, passes through the virtual loopback device driver, and raises software interrupts (NET_RX_SOFTIRQ). Upon reaching the proxy process, the entire pipeline is repeated in reverse to deliver data into userspace.

When the proxy forwards the payload into a tunnel device (such as a WireGuard or RiceGuard virtual adapter), the data undergoes yet another complete traversal. Under heavy concurrency—thousands of active TCP streams generated by modern web browsers or microservices—this redundant protocol overhead consumes over 25% of total host CPU cycles in memory allocations and softirq handling, causing latency spikes and packet serialization bottlenecks.

Architectural Deep Dive: BPF Sockmap and sk_msg Programs

Linux kernel developers introduced sockmap and stream parser infrastructure (initially merged in Linux 4.14 and stabilized in Linux 5.x) to permit direct memory splicing between established sockets. The architecture couples two distinct eBPF program types with a shared kernel map:

1. Intercepting Socket State with BPF_PROG_TYPE_SOCK_OPS

The socket operations program attaches to a cgroup hierarchy. Whenever a TCP socket within that cgroup transitions between states, the kernel triggers the attached sock_ops program with an event context (bpf_sock_ops).

During connection establishment—specifically upon reaching BPF_SOCK_OPS_ACTIVE_ESTABLISHED_CB (for outbound client sockets) and BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB (for inbound proxy listener connections)—the eBPF program extracts the socket's 4-tuple key:

struct sock_key {
    __u32 sip4;
    __u32 dip4;
    __u32 sport;
    __u32 dport;
};

struct {
    __uint(type, BPF_MAP_TYPE_SOCKHASH);
    __uint(max_entries, 65536);
    __type(key, struct sock_key);
    __type(value, __u64);
} proxy_sock_map SEC(".maps");

SEC("sockops")
int bpf_sockmap_ops(struct bpf_sock_ops *skops) {
    if (skops->family != AF_INET)
        return 1;

    switch (skops->op) {
    case BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB:
    case BPF_SOCK_OPS_ACTIVE_ESTABLISHED_CB: {
        struct sock_key key = {
            .sip4  = skops->local_ip4,
            .dip4  = skops->remote_ip4,
            .sport = bpf_ntohl(skops->local_port),
            .dport = skops->remote_port,
        };
        /* Register established socket into kernel hash map */
        bpf_sock_hash_update(skops, &proxy_sock_map, &key, BPF_ANY);
        break;
    }
    default:
        break;
    }
    return 1;
}

The call to bpf_sock_hash_update() registers the kernel socket structure (struct sock *) directly inside proxy_sock_map. The socket file descriptor remains fully accessible to userspace applications, but the kernel maintains an indexed reference to its internal memory queues.

2. Zero-Traversal Redirection with BPF_PROG_TYPE_SK_MSG

The second component attaches directly to the proxy_sock_map using the BPF_SK_MSG_VERDICT attach point. When an application initiates a sendmsg() or write() system call, the kernel executes the sk_msg program prior to packetization:

SEC("sk_msg")
int bpf_sk_msg_redirect(struct sk_msg_md *msg) {
    struct sock_key lookup_key = {
        .sip4  = msg->remote_ip4,
        .dip4  = msg->local_ip4,
        .sport = msg->remote_port,
        .dport = bpf_ntohl(msg->local_port),
    };

    /* Splicing: redirect message directly to peer socket receive queue */
    int ret = bpf_msg_redirect_hash(msg, &proxy_sock_map, &lookup_key, BPF_F_INGRESS);
    if (ret == SK_PASS)
        return SK_PASS;

    return SK_PASS;
}

When bpf_msg_redirect_hash() locates the matching peer socket in the hash table, it immediately detaches the data scatter-gather list from the sender's write queue and enqueues it directly onto the peer's receive queue (sk_receive_queue).

The entire layer 3 and layer 4 path is eliminated:

• No sk_buff network packet allocations occur.
• TCP sequence tracking and window calculations are preserved at the socket layer without issuing wire packets.
• Netfilter filters and iptables evaluation routines never fire.
• Zero software interrupts (ksoftirqd) are scheduled on the loopback device.

Quantitative Performance Comparison

Deploying sockmap redirection on Linux-based VPN gateway systems yields substantial improvements in throughput, latency distribution, and CPU consumption:

By skipping intermediate TCP/IP headers and buffer copies, CPU cores retain hotter instruction and data caches, preventing context-switch churn between application threads and network softirq routines.

Production Integration with VPNRice and RiceGuard

In modern VPN infrastructure, secure split-tunneling and encrypted local DNS caching represent critical functional requirements. VPNRice incorporates eBPF sockmap redirection within its enterprise Linux endpoints and RiceGuard gateway nodes:

[ Workstation Browser ]
       |
       | (Direct Socket Splice via eBPF sk_msg)
       v
[ RiceGuard Local Relay Daemon ]
       |
       | ChaCha20-Poly1305 AEAD Tunneling
       v
[ Global VPNRice Anycast Ingress Node ]

1. RiceGuard Local Relays: Client desktop applications dispatch requests through a hardened local Unix domain or TCP loopback relay. With eBPF sockmap enabled, local inter-process transfers occur with near-native shared memory speeds, allowing RiceGuard cryptographic engines to saturate high-bandwidth symmetric connections without host CPU starvation.
2. DNS Leak Prevention: Secure DNS resolution daemons capture loopback DNS requests (UDP/TCP port 53) and forward them via TLS or HTTPS to authenticated resolvers. Sockmap acceleration handles stream forwarding across namespaces without introducing latency penalties to DNS query rounds.
3. Containerized Mesh Integration: On edge gateways running isolated tenant containers, sockmap enables cross-container communication through transparent socket splicing, maintaining isolation policies while eradicating bridge network packet penalties.

Kernel Prerequisites and Deployment Verification

To activate eBPF sockmap redirection in production environments, ensure your Linux kernel (version 5.10 or later recommended) is compiled with required stream parser configurations:

# Verify active kernel compilation flags
zcat /proc/config.gz | grep -E "CONFIG_BPF_STREAM_PARSER|CONFIG_NET_SOCK_MSG"
# Expected output:
# CONFIG_BPF_STREAM_PARSER = y
# CONFIG_NET_SOCK_MSG = y

Once loaded via a BPF loader (such as bpftool or native Go/Rust eBPF libraries), system administrators can verify attached socket maps and inspect live redirection metrics:

# Inspect loaded sockmap objects
sudo bpftool map list type sockhash

# Monitor active redirections and socket descriptors
sudo bpftool prog tracelog

The convergence of programmable kernel sockets and lightweight cryptographic tunnels establishes a new benchmark for Linux networking performance, proving that privacy and ultra-low latency can coexist seamlessly.