A dae side gateway is a Debian host on your LAN that runs dae, an eBPF-based transparent proxy, while the main router keeps DHCP and the internet connection. Bind dae to the LAN interface only, point a single device's gateway at the host, and prove that the device returns to normal when you undo that change. This procedure is based on the official sources listed below; a complete end-to-end test has not been performed.

Key Takeaways

dae needs Linux 5.17 or later and specific BPF kernel options to bind to a LAN.

Binding only lan_interface leaves the Debian host's own programs unproxied.

On a single-arm gateway, ICMP redirects can send clients around dae unless both redirect switches are off.

Recovery for the test device is simply restoring its original gateway and DNS.

What does a dae side gateway do differently?

A dae eBPF transparent proxy places its traffic-splitting logic inside the Linux kernel. Direct traffic can then pass without going through a user-space proxy, which the project calls Real Direct and which requires IP forwarding.［1］ The proxy side still connects to nodes you define, using links such as VLESS, Trojan or Shadowsocks.［2］

This guide builds a Debian side gateway with dae. If your spare device runs OpenWrt, the OpenWrt single-arm gateway procedure covers that platform. If you are still choosing a capture method, the REDIRECT, TPROXY and TUN comparison explains the classic rule-based options; dae uses its own eBPF programs instead of rules you maintain by hand.

Running any gateway means you own its updates, failures and logs. The operator checklist for self-hosted services lists those duties, and it is worth comparing a server you maintain with a managed VPN service before you commit household traffic to one.

Step 1: Check the Debian kernel and network layout

The baseline is dae v2.1.1, read from that release tag's documentation. The quick start lists Linux 5.17 as the minimum for binding to a LAN or WAN interface and 5.15 for dae trace.［3］

uname -r
(zcat /proc/config.gz || cat /boot/config-$(uname -r)) | grep -E 'CONFIG_(BPF|BPF_SYSCALL|BPF_JIT|DEBUG_INFO_BTF|NET_CLS_BPF|NET_SCH_INGRESS|KPROBES)='
ip -4 addr show
ip route show default

The quick start lists the full set of required options, including CONFIG_BPF_SYSCALL=y, CONFIG_DEBUG_INFO_BTF=y and CONFIG_NET_CLS_BPF=m. Desktop distributions usually enable them, while embedded builds may not.［3］ Stop if any required option is missing; do not try to load modules from other kernels.

Write down the layout you will use. This guide assumes the main router is 192.168.1.1, the Debian host has a fixed address 192.168.1.2 on interface eth0, and both sit on the same LAN. Reserve the host address in the router's DHCP settings rather than changing who runs DHCP.

Step 2: Install dae from the project repository

For Debian and Ubuntu, the quick start uses the Dae Universe APT repository. Choose the .sources file for APT 3.0 or later, or the .list file for older APT, then import the signing key and install.［3］

sudo apt update && sudo apt install curl
sudo curl -fsSL -o /etc/apt/sources.list.d/daeuniverse.sources https://daeuniverse.pages.dev/daeuniverse.sources
sudo curl -fsSL -o /usr/share/keyrings/daeuniverse-archive-goose.gpg https://daeuniverse.pages.dev/daeuniverse-archive-goose.gpg
sudo apt update && sudo apt install dae
dae --version

The package installs a systemd service and an example at /etc/dae/example.dae; your configuration goes in /etc/dae/config.dae.［3］ Do not start the service yet. Confirm the reported version and keep a note of it next to your layout.

Step 3: Write a minimal LAN-only configuration

Create /etc/dae/config.dae with chmod 600, because it holds node credentials. The following configuration binds only the LAN interface, defines one node you own or may use, and sends everything that is not local or multicast to that node.［2］［3］

global {
  lan_interface: eth0
  log_level: info
  allow_insecure: false
  auto_config_kernel_parameter: true
}

node {
  mynode: 'vless://REPLACE_WITH_YOUR_OWN_LINK'
}

dns {
  upstream {
    googledns: 'tcp+udp://dns.google:53'
  }
  routing {
    request {
      fallback: googledns
    }
  }
}

group {
  proxy {
    filter: name(mynode)
    policy: fixed(0)
  }
}

routing {
  dip(224.0.0.0/3, 'ff00::/8') -> direct
  dip(geoip:private) -> direct
  fallback: proxy
}

Leaving out wan_interface is deliberate. According to the quick start, a LAN-only binding affects traffic from LAN devices while the host's own programs, including SSH and package updates, stay unaffected.［3］ Keep allow_insecure: false, so a certificate problem fails visibly instead of being hidden.

Validate before starting. The project's systemd unit runs the same check as ExecStartPre, and the validation pass touches no BPF state or network.［4］

sudo dae validate -c /etc/dae/config.dae

Step 4: Check forwarding and ICMP redirects

With auto_config_kernel_parameter: true, dae sets the kernel parameters for the LAN interfaces it binds, including forwarding and send_redirects.［2］［5］ On a single-arm gateway, a client's packet enters and leaves on the same interface, so the kernel would normally send an ICMP redirect telling the client to use the main router directly, around dae.

The kernel treats send_redirects on an interface as enabled when either conf/all or conf/<interface> is on, so both must be 0.［6］ Start dae, then read the values:

sudo systemctl start dae
sysctl net.ipv4.ip_forward net.ipv4.conf.all.send_redirects net.ipv4.conf.eth0.send_redirects

If all is still 1, add net.ipv4.conf.all.send_redirects = 0 to a file under /etc/sysctl.d/ and run sudo sysctl --system. Also note that dae sets net.ipv4.conf.all.rp_filter = 0 and adjusts its own dae0 interface each time it starts; record your previous values so you can restore them after an uninstall.［5］

Step 5: Point one device at the side gateway

Pick one laptop or desktop with a wired or stable Wi-Fi connection. Record its current DHCP-assigned address, gateway and DNS. Then set a manual IPv4 configuration: same address, gateway 192.168.1.2, and DNS 192.168.1.1.

Keeping DNS on the main router is intentional. dae intercepts UDP and TCP port 53 traffic that it routes, so the test device's queries to the router still pass through dae's DNS module and follow your dns section.［7］ The troubleshooting guide also warns that a suspended dae does not intercept DNS, which is why the gateway host should not be advertised as the DNS server.［8］

Step 6: Verify exit, DNS and LAN access

Use these as expected observations and write down your own results.

Check method	Expected observation	If it fails
Open the IP check page on the test device	The node's public address appears	Read `journalctl -u dae` and the node link
Same page on another device	Your normal ISP address appears	You changed the wrong device or DHCP
Resolve a name on the test device	Answers arrive without errors	Check the upstream and `dip(geoip:private)` rule
Open the router admin page and a LAN share	Local addresses still work	Confirm the private-address rule is first
`sysctl` redirect values on the host	Both `send_redirects` values are 0	Fix the sysctl file and restart dae

For the exit check, view the public address the test device presents. A changed address shows that web traffic reaches the node; DNS and LAN access still need their own checks above.

Step 7: Test failure recovery and uninstall

Run the failure test while you are at the device. Stop dae with sudo systemctl stop dae; the test device should either lose internet access or fall back to direct forwarding, depending on the host's forwarding state. Then restore the device's original DHCP settings and confirm normal browsing. That restore is your recovery path for any later fault, including a power cut on the Debian host.

Only after a clean recovery should you run sudo systemctl enable dae. Enabling at boot does not start the service immediately.［3］ For configuration changes, dae reload applies them without interrupting existing connections, and dae suspend pauses dae temporarily.［3］

To uninstall, restore every device's DHCP settings first, then run sudo systemctl disable --now dae, sudo apt remove dae, and delete the repository file, keyring and any sysctl files you added. Restore the rp_filter value you recorded and reboot if you are unsure what dae left behind.

Which traffic does this setup leave untouched?

The host's own programs are outside the LAN-only binding, so updating Debian or running SSH from it does not use the node.［3］ Other LAN devices keep the main router as their gateway and are unaffected, apart from any change you make to them.

IPv6 is the common gap. Hosts learn default routers from Router Advertisements, so a test device with a global IPv6 address keeps sending IPv6 to the main router even after you change its IPv4 gateway.［9］ Either test an IPv4-only path and record that limit, or plan IPv6 separately before widening.

When should you widen beyond one device?

Widen only after the exit, DNS, LAN and recovery checks pass and the host has survived a reboot with dae enabled. Add devices one at a time with manual gateway settings first. Changing the main router's DHCP gateway option affects every client at once, so keep that for last.

Keep the main router as the DNS server you hand out, for the suspend reason above.［8］ If the Debian host must also run a local DNS service, read dae's DNS documentation on must_direct rules first, because port 53 traffic to the host is handled differently by those rules.［7］

Summary

Confirm Linux 5.17 or later and the BPF options before installing dae v2.1.1.
Bind only lan_interface, validate the configuration, and keep the node credentials private.
Make sure both send_redirects switches are off so clients do not bypass dae.
Test one device's exit, DNS and LAN access, then rehearse recovery before enabling at boot.

FAQ

Does dae proxy the Debian host's own traffic?

Not with this configuration. Only lan_interface is bound, so dae handles traffic from LAN devices, while the host's own programs keep their normal route.

What kernel version does dae need for a side gateway?

The dae quick start lists Linux 5.17 as the minimum for binding to a LAN interface, together with BPF and BTF kernel options that you can check in the kernel configuration.

Why do I need to turn off ICMP redirects?

On a single-arm gateway, the kernel would tell clients to send traffic straight to the main router. Redirects stay enabled if either the global or interface switch is on.

Should I make the Debian host my DHCP server?

No. Keep DHCP on the main router and change one device manually. That keeps recovery simple and avoids two DHCP servers competing on the same LAN.

Why set the test device's DNS to the main router?

dae intercepts port 53 traffic it routes, so queries still pass through its DNS module. If dae is suspended, those queries also keep working through the router.

What happens if the Debian host loses power?

Devices using it as gateway lose internet access until they use the main router again. Restoring the test device's DHCP settings is the recovery path, so rehearse it first.

Is dae the same as using TPROXY rules myself?

No. dae implements its capture and splitting with eBPF programs, so you do not maintain your own TPROXY or REDIRECT rules, though the same LAN design questions still apply.

Disclaimer: This article is for general informational purposes only and does not constitute legal, technical, or other professional advice. We make no guarantees regarding the accuracy, completeness, or timeliness of the content. Use only networks, hosts and proxy nodes you own or are authorized to use.

Sources:

daeuniverse — dae README (v2.1.1) — https://github.com/daeuniverse/dae/blob/v2.1.1/README.md
daeuniverse — example.dae (v2.1.1) — https://github.com/daeuniverse/dae/blob/v2.1.1/example.dae
daeuniverse — dae Quick Start Guide (v2.1.1) — https://github.com/daeuniverse/dae/blob/v2.1.1/docs/en/README.md
daeuniverse — dae systemd unit (v2.1.1) — https://github.com/daeuniverse/dae/blob/v2.1.1/install/dae.service
daeuniverse — Configure Kernel Parameters (v2.1.1) — https://github.com/daeuniverse/dae/blob/v2.1.1/docs/en/user-guide/kernel-parameters.md
Linux kernel — IP sysctl — https://docs.kernel.org/networking/ip-sysctl.html
daeuniverse — DNS configuration (v2.1.1) — https://github.com/daeuniverse/dae/blob/v2.1.1/docs/en/configuration/dns.md
daeuniverse — Troubleshooting (v2.1.1) — https://github.com/daeuniverse/dae/blob/v2.1.1/docs/en/troubleshooting.md
IETF — RFC 4861, Neighbor Discovery for IP version 6 (IPv6) — https://www.rfc-editor.org/rfc/rfc4861

Sources checked 14 October 2026.

Related articles:

dae Side Gateway on Debian: Setup, DNS and Recovery