AdguardTeam / AdguardTeam/AdGuardHome

Binding on 0.0.0.0 causing asymmetric routing on multihomed hosts

未关闭
#8,109 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看
主要语言
TypeScript
星标
36.9k
派生
2.5k
PR 合并指标
30 天内没有已合并 PR

描述

### Prerequisites

- [x] I have checked the [Wiki](https://github.com/AdguardTeam/AdGuardHome/wiki) and [Discussions](https://github.com/AdguardTeam/AdGuardHome/discussions/categories/q-a) and found no answer

- [x] I have searched other issues and found no duplicates

- [x] I want to report a bug and not [ask a question or ask for help](https://github.com/AdguardTeam/AdGuardHome/discussions/categories/q-a)

- [x] I have set up AdGuard Home correctly and [configured clients to use it](https://github.com/AdguardTeam/AdGuardHome/wiki/Clients). (Use the [Discussions](https://github.com/AdguardTeam/AdGuardHome/discussions/categories/q-a) for help with installing and configuring clients.)

### Platform (OS and CPU architecture)

FreeBSD, AMD64 (aka x86_64)

### Installation

Custom package (OpenWrt, HomeAssistant, etc; please mention in the description)

### Setup

On one machine

### AdGuard Home version

v0.107.69

### Action

On a OPNsense router:
1. Configured LAN 192.168.0.1 on igc0.
2. Created VLAN30 as vlan0.30 and terminated it with IP 192.168.30.1.
3. Allowed any traffic in the firewall for VLAN30.
4. AdGuard bound on 0.0.0.0.

On a UNRAID NAS:
1. Configured eth0 with IP 192.168.0.2.
2. Configured OPNsense router as DNS, 192.168.0.1.
3. Configured eth0.30 with IP 192.168.30.2.
4. Created a macvlan docker network with parent eth0.30.
5. Created a container in the macvlan network and assigned IP 192.168.30.3.

On a managed switch:
1. Tagged the port for OPNsense and UNRAID with ID 30 and kept them untagged on default vlan.

On the container created in the UNRAID NAS:
1. nslookup google.com

### Expected result

The expected result would be a successful query.

### Actual result

Query timed out.

### Additional information and/or screenshots

The DNS is running on 192.168.0.1 and is reachable from 192.168.30.3. The issue is related to asymmetric routing.

With a tcpdump `tcpdump -i vlan0.30 -nn port 53` on OPNsense, we can see that the query packet arrives from 192.168.30.3 to 192.168.0.1, but when it leaves OPNsense, its source is modified from 192.168.0.1 to 192.168.30.1.

This is probably due to some specific behavior of the FreeBSD kernel. The workaround is to bind to specific interfaces. I think something could be done to fix this, considering that Unbound works well in this very same setup.

贡献指南

打开贡献指南

评估

这个 Issue 还没有评估数据。

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。