[Bug] immortalwrt 23.05 默认配置，开启白名单后路由器本身无法上网，外网也连不进来 #797

bsdcpp · 2024-10-16T10:23:40Z

Verify steps

我已经在 Issue Tracker 中找过我要提出的问题 I have searched on the issue tracker for a related issue.
我已经使用公测版本测试过，问题依旧存在 I have tested using the test mod, and the issue still exists.
我已经仔细看过常见问题并无法自行解决问题

Description

全新安装的情况下也能复现，切换黑名单/关闭sc马上恢复。局域网设备好像不受影响，路由器本身国内163,baidu都无法ping通，谢谢。
shellcrash新装默认配置，只改了tproxy：nftables + tproxy + fake

juewuy · 2024-10-16T10:35:38Z

@bsdcpp 脚本什么版本，另外是否启用了本机代理，然后提供一下问题状态的8-1-4内容

bsdcpp · 2024-10-16T10:45:23Z

版本：1.9.1rc7
这是默认黑名单情况

table inet shellcrash {
	chain input {
		type filter hook input priority -100; policy accept;
		ip daddr 127.0.0.1 accept
		tcp dport 9999 ip saddr { 10.0.8.0/24, 192.168.1.0-192.168.3.255 } accept
		tcp dport 9999 reject
		tcp dport 7890 ip saddr { 10.0.8.0/24, 192.168.1.0-192.168.3.255 } accept
		tcp dport 7890 reject
	}

	chain prerouting_dns {
		type nat hook prerouting priority dstnat; policy accept;
		udp dport != 53 return
		tcp dport != 53 return
		meta mark 0x00001ed6 return
		meta skgid { 453, 7890 } return
		ip saddr != { 10.0.8.0/24, 192.168.1.0-192.168.3.255 } return
		ip6 saddr != { 2408:820c:8211:f179::/64, 2408:820c:8218:7c90::/60, 240e:388:8101:df00::/60, 240e:38f:8105:2038::/64, fd00::/8, fe80::/10 } reject with icmpv6 port-unreachable
		udp dport 53 redirect to :1053
		tcp dport 53 redirect to :1053
	}

	chain prerouting {
		type filter hook prerouting priority mangle; policy accept;
		tcp dport 53 return
		udp dport 53 return
		tcp dport != { 22, 80, 143, 194, 443, 465, 587, 853, 993, 995, 5222, 8080, 8443 } ip daddr != 198.18.0.0/16 return
		meta mark 0x00001ed6 return
		meta skgid 7890 return
		ip daddr { 0.0.0.0/8, 10.0.0.0/8, 100.64.0.0/10, 127.0.0.0/8, 169.254.0.0/16, 172.16.0.0/12, 192.168.0.0/16, 224.0.0.0/3 } return
		ip saddr != { 10.0.8.0/24, 192.168.1.0-192.168.3.255 } return
		ip6 daddr { ::/127, ::ffff:0.0.0.0/96, 64:ff9b::/96, 100::/64, 2001::/32, 2001:20::/28, 2001:db8::/32, 2002::/16, 2408:820c:8211:f179::/64, 2408:820c:8218:7c90::/60, 240e:388:8101:df00::/60, 240e:38f:8105:2038::/64, fc00::/7, fe80::/10, ff00::/8 } return
		ip6 saddr != { 2408:820c:8211:f179::/64, 2408:820c:8218:7c90::/60, 240e:388:8101:df00::/60, 240e:38f:8105:2038::/64, fd00::/8, fe80::/10 } return
		meta l4proto { tcp, udp } meta mark set 0x00001ed4 tproxy to :7893
	}
}

以下是白名单不正常的情况：

table inet shellcrash {
	chain input {
		type filter hook input priority -100; policy accept;
		ip daddr 127.0.0.1 accept
		tcp dport 9999 ip saddr { 10.0.8.0/24, 192.168.1.0-192.168.3.255 } accept
		tcp dport 9999 reject
		tcp dport 7890 ip saddr { 10.0.8.0/24, 192.168.1.0-192.168.3.255 } accept
		tcp dport 7890 reject
	}

	chain prerouting_dns {
		type nat hook prerouting priority dstnat; policy accept;
		udp dport != 53 return
		tcp dport != 53 return
		meta mark 0x00001ed6 return
		meta skgid { 453, 7890 } return
		ip saddr != { 10.0.8.0/24, 192.168.1.0-192.168.3.255 } return
		ip6 saddr != { 2408:820c:8211:f179::/64, 2408:820c:8218:7c90::/60, 240e:388:8101:df00::/60, 240e:38f:8105:2038::/64, fd00::/8, fe80::/10 } reject with icmpv6 port-unreachable
		udp dport 53 redirect to :1053
		tcp dport 53 redirect to :1053
	}

	chain prerouting {
		type filter hook prerouting priority mangle; policy accept;
		tcp dport 53 return
		udp dport 53 return
		tcp dport != { 22, 80, 143, 194, 443, 465, 587, 853, 993, 995, 5222, 8080, 8443 } ip daddr != 198.18.0.0/16 return
		meta mark 0x00001ed6 return
		meta skgid 7890 return
		ip daddr { 0.0.0.0/8, 10.0.0.0/8, 100.64.0.0/10, 127.0.0.0/8, 169.254.0.0/16, 172.16.0.0/12, 192.168.0.0/16, 224.0.0.0/3 } return
		ip6 daddr { ::/127, ::ffff:0.0.0.0/96, 64:ff9b::/96, 100::/64, 2001::/32, 2001:20::/28, 2001:db8::/32, 2002::/16, 2408:820c:8211:f179::/64, 2408:820c:8218:7c90::/60, 240e:388:8101:df00::/60, 240e:38f:8105:2038::/64, fc00::/7, fe80::/10, ff00::/8 } return
		ip6 saddr != { 2408:820c:8211:f179::/64, 2408:820c:8218:7c90::/60, 240e:388:8101:df00::/60, 240e:38f:8105:2038::/64, fd00::/8, fe80::/10 } return
		meta l4proto { tcp, udp } meta mark set 0x00001ed4 tproxy to :7893
	}
}

对比后，差异在 ip saddr != { 10.0.8.0/24, 192.168.1.0-192.168.3.255 } return

juewuy · 2024-10-16T10:48:48Z

@bsdcpp 看不出问题，防火墙配置是正常的，理论上也不会影响本机

bsdcpp · 2024-10-16T10:50:04Z

@bsdcpp 看不出问题，防火墙配置是正常的，理论上也不会影响本机

我更新了下回复，麻烦再看下。

juewuy · 2024-10-16T10:52:29Z

@bsdcpp 这里防火墙配置都是正常的，prerouting链也不会影响本机流量

juewuy · 2024-10-16T10:58:42Z

@bsdcpp 如果是在docker中测试，需要启用容器/虚拟机代理功能

bsdcpp · 2024-10-16T11:00:24Z

我是在真机环境下安装的，之前用iptables是没问题的，我再调试下看看，顺便学习下nft，感谢大佬解答，售后一级棒🎉

bsdcpp · 2024-10-16T14:10:50Z

@juewuy
通过tcpdump观察，开黑名单的时候：

22:07:26.882400 pppoe-wan In  IP 进入IP.32964 > 服务端IP.50000: UDP, length 96
22:07:26.937646 pppoe-wan Out IP 服务端IP.50000 > 进入IP.32964: UDP, length 96
22:07:26.994227 pppoe-wan In  IP 进入IP.32964 > 服务端IP.50000: UDP, length 96
22:07:27.561369 pppoe-wan In  IP 进入IP.32964 > 服务端IP.50000: UDP, length 96
22:07:27.671277 pppoe-wan In  IP 进入IP.32964 > 服务端IP.50000: UDP, length 96
22:07:28.006316 pppoe-wan In  IP 进入IP.32964 > 服务端IP.50000: UDP, length 96
22:07:28.618137 pppoe-wan Out IP 服务端IP.50000 > 进入IP.32964: UDP, length 96

一旦开白名单，似乎有包进了lo，回环了吗，只有进没有出了？
可以看到pppoe-wan In IP 进入IP.发了一个148长度的包，接下来下一条服务器照同样大小也发了一份，并且发给了lo，然后又回给了自己。

22:07:28.652399 pppoe-wan In  IP 进入IP.32964 > 服务端IP.50000: UDP, length 148
22:07:28.665062 lo    In  IP 服务端IP.33441 > 服务端IP.50000: UDP, length 148
22:07:28.777946 lo    In  IP 服务端IP.50000 > 服务端IP.33441: UDP, length 92
22:07:28.778022 lo    In  IP 服务端IP.50000 > 服务端IP.33441: UDP, length 92
22:07:28.842484 pppoe-wan In  IP 进入IP.32964 > 服务端IP.50000: UDP, length 148
22:07:28.850514 lo    In  IP 服务端IP.48605 > 服务端IP.50000: UDP, length 92
22:07:28.850914 lo    In  IP 服务端IP.50000 > 服务端IP.48605: UDP, length 92
22:07:28.938108 lo    In  IP 服务端IP.50000 > 服务端IP.48605: UDP, length 92
22:07:29.098005 lo    In  IP 服务端IP.50000 > 服务端IP.48605: UDP, length 92
22:07:29.201430 pppoe-wan In  IP 进入IP.32964 > 服务端IP.50000: UDP, length 92

貌似之前看到过这样的问题，不知道是不是同一类问题：#783
他影响的是DNAT转发内网的，我直接影响本机😂

请教下，这个流是不是进入核心了？

root@ImmortalWrt:/etc# ip ru
0:	from all lookup local
32765:	from all fwmark 0x1ed4 lookup 100
32766:	from all lookup main
32767:	from all lookup default
root@ImmortalWrt:/etc# ip r list table 100
local default dev lo scope host
root@ImmortalWrt:/etc#

没看懂，tproxy走的是个lo接口？

pleasant98 · 2024-10-17T10:18:25Z

我这边是把ipv6透明代理关了就能通过ipv6访问局域网设备了

bsdcpp · 2024-10-17T10:20:21Z

我这边是把ipv6透明代理关了就能通过ipv6访问局域网设备了

谢谢反馈，我现在只能用黑名单模式，和nft/iptables关系不大

juewuy · 2024-10-19T06:24:14Z

@juewuy 通过tcpdump观察，开黑名单的时候：

22:07:26.882400 pppoe-wan In  IP 进入IP.32964 > 服务端IP.50000: UDP, length 96
22:07:26.937646 pppoe-wan Out IP 服务端IP.50000 > 进入IP.32964: UDP, length 96
22:07:26.994227 pppoe-wan In  IP 进入IP.32964 > 服务端IP.50000: UDP, length 96
22:07:27.561369 pppoe-wan In  IP 进入IP.32964 > 服务端IP.50000: UDP, length 96
22:07:27.671277 pppoe-wan In  IP 进入IP.32964 > 服务端IP.50000: UDP, length 96
22:07:28.006316 pppoe-wan In  IP 进入IP.32964 > 服务端IP.50000: UDP, length 96
22:07:28.618137 pppoe-wan Out IP 服务端IP.50000 > 进入IP.32964: UDP, length 96

一旦开白名单，似乎有包进了lo，回环了吗，只有进没有出了？可以看到pppoe-wan In IP 进入IP.发了一个148长度的包，接下来下一条服务器照同样大小也发了一份，并且发给了lo，然后又回给了自己。

22:07:28.652399 pppoe-wan In  IP 进入IP.32964 > 服务端IP.50000: UDP, length 148
22:07:28.665062 lo    In  IP 服务端IP.33441 > 服务端IP.50000: UDP, length 148
22:07:28.777946 lo    In  IP 服务端IP.50000 > 服务端IP.33441: UDP, length 92
22:07:28.778022 lo    In  IP 服务端IP.50000 > 服务端IP.33441: UDP, length 92
22:07:28.842484 pppoe-wan In  IP 进入IP.32964 > 服务端IP.50000: UDP, length 148
22:07:28.850514 lo    In  IP 服务端IP.48605 > 服务端IP.50000: UDP, length 92
22:07:28.850914 lo    In  IP 服务端IP.50000 > 服务端IP.48605: UDP, length 92
22:07:28.938108 lo    In  IP 服务端IP.50000 > 服务端IP.48605: UDP, length 92
22:07:29.098005 lo    In  IP 服务端IP.50000 > 服务端IP.48605: UDP, length 92
22:07:29.201430 pppoe-wan In  IP 进入IP.32964 > 服务端IP.50000: UDP, length 92

貌似之前看到过这样的问题，不知道是不是同一类问题：#783 他影响的是DNAT转发内网的，我直接影响本机😂

请教下，这个流是不是进入核心了？

root@ImmortalWrt:/etc# ip ru
0:	from all lookup local
32765:	from all fwmark 0x1ed4 lookup 100
32766:	from all lookup main
32767:	from all lookup default
root@ImmortalWrt:/etc# ip r list table 100
local default dev lo scope host
root@ImmortalWrt:/etc#

没看懂，tproxy走的是个lo接口？

lo没问题啊，有问题的是为什么流量会进到内核，不进内核不会被打上标记

juewuy · 2024-10-19T06:44:37Z

@juewuy c98e50b

bsdcpp · 2024-10-19T09:42:41Z

感谢修复，不过我测试了下，还是挺烧脑的：
外网wg进来是10.0.8.0/24网段，只添加了白名单mac。
nftables:

redir ：都没有问题
tproxy/tun ：wg无法访问内外网

iptables:
Redir/tproxy/tun: wg进来可以访问正常；局域网设备内外网正常，但离奇的是无法访问clash api的控制网页

juewuy · 2024-10-19T10:04:13Z

@bsdcpp 进阶设置防火墙里可能需要添加一下自定义网段

bsdcpp · 2024-10-19T10:10:58Z

@bsdcpp 进阶设置防火墙里可能需要添加一下自定义网段

谢谢，里面已经有10.0.8.1/24段了，而且新的immortalwrt有点难搞：
redir + nftables 模式，怎么感觉规则有重复

chain prerouting {
		type nat hook prerouting priority dstnat; policy accept;
		tcp dport 53 return
		udp dport 53 return
		tcp dport != { 22, 80, 143, 194, 443, 465, 587, 853, 993, 995, 5222, 8080, 8443 } ip daddr != 198.18.0.0/16 return
		meta mark 0x00001ed6 return
		meta skgid 7890 return
		ip daddr 0.0.0.0 return
		ether saddr != { 00:04:4b:84:20:ac,fc:7c:02:92:b4:fa } ip saddr != 10.0.8.0/24 return
		meta nfproto ipv6 return
		meta l4proto tcp redirect to :7892
		tcp dport 53 return
		udp dport 53 return
		tcp dport != { 22, 80, 143, 194, 443, 465, 587, 853, 993, 995, 5222, 8080, 8443 } ip daddr != 198.18.0.0/16 return
		meta mark 0x00001ed6 return
		meta skgid 7890 return
		ip daddr 0.0.0.0 return
		ether saddr != { 00:04:4b:84:20:ac, fc:7c:02:92:b4:fa } ip saddr != 10.0.8.0/24 return
		meta nfproto ipv6 return
		meta l4proto { tcp, udp } meta mark set 0x00001ed4 tproxy to :7893
	}

juewuy · 2024-10-19T10:13:49Z

@bsdcpp 重启设备吧，感觉有点乱

bsdcpp · 2024-10-19T10:18:58Z

重启immortalwrt后还是一样的情况

juewuy · 2024-10-19T10:19:39Z

@bsdcpp 好吧，明天有空我看一下

bsdcpp · 2024-10-19T10:23:05Z

感谢，等你方便的时候，我主要用老的21的openwrt，一直很稳，这个新系统包括nftables确实比较令人崩溃。
我先看下是哪里执行了两次，sc重启有个报错：

Error: Could not process rule: File exists
add chain inet shellcrash prerouting { type filter hook prerouting priority -150 ; }
                          ^^^^^^^^^^

bsdcpp · 2024-10-19T10:41:39Z

应该是这行判断导致

ShellCrash/scripts/start.sh

Line 1314 in 1bcd7b6

    
           	[ "$redir_mod" = "Tproxy模式" ] && modprobe nft_tproxy >/dev/null 2>&1 || lsmod 2>/dev/null | grep -q nft_tproxy && {

改成

[ "$redir_mod" = "Tproxy模式" ] && ( modprobe nft_tproxy >/dev/null 2>&1 || lsmod 2>/dev/null | grep -q nft_tproxy ) && {

没有重复

juewuy · 2024-10-19T10:43:00Z

@bsdcpp OK

bsdcpp · 2024-10-19T12:51:59Z

对比了下nft和ipt的区别，mangle表里ipt的tproxy处理规则

Chain shellcrash_mark (4 references)
target     prot opt source               destination
RETURN     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:53
RETURN     udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:53
RETURN     all  --  0.0.0.0/0            0.0.0.0/0            mark match 0x1ed6
RETURN     all  --  0.0.0.0/0            192.168.1.0/24
RETURN     all  --  0.0.0.0/0            192.168.3.0/24
RETURN     all  --  0.0.0.0/0            192.168.2.0/24
RETURN     all  --  0.0.0.0/0            192.168.77.0/24
RETURN     all  --  0.0.0.0/0            10.0.8.0/24
RETURN     all  --  0.0.0.0/0            0.0.0.0
TPROXY     tcp  --  0.0.0.0/0            0.0.0.0/0            MAC cc:2d:b5:69:85:cd TPROXY redirect 0.0.0.0:7893 mark 0x1ed4/0xffffffff
TPROXY     tcp  --  0.0.0.0/0            0.0.0.0/0            MAC 00:e1:4e:b4:48:9c TPROXY redirect 0.0.0.0:7893 mark 0x1ed4/0xffffffff

nft:

chain prerouting {
		type filter hook prerouting priority mangle; policy accept;
		tcp dport 53 return
		udp dport 53 return
		tcp dport != { 22, 80, 143, 194, 443, 465, 587, 853, 993, 995, 5222, 8080, 8443 } ip daddr != 198.18.0.0/16 return
		meta mark 0x00001ed6 return
		meta skgid 7890 return
		ip daddr 0.0.0.0 return
		ether saddr != { cc:2d:b5:69:85:cd, 00:e1:4e:b4:48:9c } return
		meta nfproto ipv6 return
		meta l4proto { tcp, udp } meta mark set 0x00001ed4 tproxy to :7893
	}

相比较，nft的好似不一样，具体逻辑我不太懂：

daddr { 10.0.8.0/24, 192.168.1.0-192.168.3.255, 192.168.77.0/24, 0.0.0.0/32 }的没有return
只要前面没有return的全部set mark 0x00001ed4，而ipt是匹配mac的才一一set，是不是改成类似会好点
ether saddr = { cc:2d:b5:69:85:cd, 00:e1:4e:b4:48:9c } meta mark set 0x00001ed4 tproxy to :7893

juewuy · 2024-10-19T12:55:48Z

@bsdcpp 1应该是bug，2应该没什么区别

bsdcpp · 2024-10-19T12:57:50Z

@bsdcpp 1应该是bug，2应该没什么区别

嗯，我就怕有什么没考虑到的通过了所有return“关卡”来到了不该打标签的地方。一些回环啥的确实烧脑，难为大佬维护，不容易

bsdcpp · 2024-10-19T13:00:16Z

还有个神奇的地方是，iptables模式，只有在路由器上用127.0.0.1地址可以访问localhost:9999，用内网192.168.2.1访问不了。

Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination
1    REJECT     udp  --  anywhere             anywhere             udp dpt:https reject-with icmp-port-unreachable
2    ACCEPT     tcp  --  anywhere             localhost
3    LUCKY      all  --  anywhere             anywhere
4    LUCKY      all  --  anywhere             anywhere
5    ACCEPT     tcp  --  0.0.0.0              anywhere             tcp dpt:9999
6    REJECT     tcp  --  anywhere             anywhere             tcp dpt:9999 reject-with icmp-port-unreachable
7    ACCEPT     tcp  --  0.0.0.0              anywhere             tcp dpt:7890
8    REJECT     tcp  --  anywhere             anywhere             tcp dpt:7890 reject-with icmp-port-unreachable

应该是被6 REJECT掉了

juewuy · 2024-10-19T13:05:25Z

@bsdcpp localhost就是你本机，当然只能在本机访问

bsdcpp · 2024-10-19T13:14:15Z

-A INPUT -s 0.0.0.0/32 -p tcp -m tcp --dport 9999 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 9999 -j REJECT --reject-with icmp-port-unreachable

是这样的，这个0.0.0.0/32正常吗？我去掉下面那个REJECT就内网设备可以访问了，是不是没匹配到这个0.0.0.0/32，导致走到了REJECT

juewuy · 2024-10-19T13:16:15Z

@bsdcpp 你这个设备有点问题，正常是会获取到局域网ip段的

juewuy · 2024-10-19T13:16:55Z

@bsdcpp getlanip这个函数里有具体命令你可以运行试试

bsdcpp · 2024-10-19T13:17:05Z

😂，是的，我看了正常的机器是：

spiderClash:/# iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     6    --  0.0.0.0/0            127.0.0.1
ACCEPT     6    --  0.0.0.0/8            0.0.0.0/0            tcp dpt:9999
ACCEPT     6    --  10.0.0.0/8           0.0.0.0/0            tcp dpt:9999
ACCEPT     6    --  127.0.0.0/8          0.0.0.0/0            tcp dpt:9999
ACCEPT     6    --  100.64.0.0/10        0.0.0.0/0            tcp dpt:9999
ACCEPT     6    --  169.254.0.0/16       0.0.0.0/0            tcp dpt:9999
ACCEPT     6    --  172.16.0.0/12        0.0.0.0/0            tcp dpt:9999
ACCEPT     6    --  192.168.0.0/16       0.0.0.0/0            tcp dpt:9999
ACCEPT     6    --  224.0.0.0/4          0.0.0.0/0            tcp dpt:9999
ACCEPT     6    --  240.0.0.0/4          0.0.0.0/0            tcp dpt:9999
REJECT     6    --  0.0.0.0/0            0.0.0.0/0            tcp dpt:9999 reject-with icmp-port-unreachable

bsdcpp · 2024-10-19T13:59:19Z

哈哈，确实，今天说的问题纯属意外，我看了下是因为我去访问7-3-4自定义内网段后，按了0返回导致reserved_ipv4='0'出现了一系列妖怪问题，抱歉。
是最近一次提交的78808be

然后回到之前，

应该是这行判断导致

ShellCrash/scripts/start.sh

Line 1314 in 1bcd7b6

[ "$redir_mod" = "Tproxy模式" ] && modprobe nft_tproxy >/dev/null 2>&1 || lsmod 2>/dev/null | grep -q nft_tproxy && {

改成
[ "$redir_mod" = "Tproxy模式" ] && ( modprobe nft_tproxy >/dev/null 2>&1 || lsmod 2>/dev/null | grep -q nft_tproxy ) && {
没有重复

这应该是一个问题。
然后标题说的tproxy模式下，按今天修复的，外面进来的依旧是内外网无法访问。
我是过一个办法，但不知道什么逻辑，目前正常，就不知道有没有漏洞请大佬有空分析下：就是仿照黑名单的办法，不管什么情况都添加一条

nft add rule inet shellcrash $1 ip saddr != {$HOST_IP} return  #仅代理本机局域网网段流量

按照今天你修复的情况

ShellCrash/scripts/start.sh

Line 1216 in d73e95c

    
           				nft add rule inet shellcrash $1 ip saddr != {$HOST_IP} return  #仅代理本机局域网网段流量

比方我白名单添加了mac/ip，走了elif分支，这样的话就不会添加上面那条了。

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Bug] immortalwrt 23.05 默认配置，开启白名单后路由器本身无法上网，外网也连不进来 #797

[Bug] immortalwrt 23.05 默认配置，开启白名单后路由器本身无法上网，外网也连不进来 #797

bsdcpp commented Oct 16, 2024 •

edited

Loading

juewuy commented Oct 16, 2024

bsdcpp commented Oct 16, 2024 •

edited

Loading

juewuy commented Oct 16, 2024

bsdcpp commented Oct 16, 2024

juewuy commented Oct 16, 2024

juewuy commented Oct 16, 2024

bsdcpp commented Oct 16, 2024

bsdcpp commented Oct 16, 2024 •

edited

Loading

pleasant98 commented Oct 17, 2024

bsdcpp commented Oct 17, 2024

juewuy commented Oct 19, 2024

juewuy commented Oct 19, 2024

bsdcpp commented Oct 19, 2024 •

edited

Loading

juewuy commented Oct 19, 2024

bsdcpp commented Oct 19, 2024 •

edited

Loading

juewuy commented Oct 19, 2024

bsdcpp commented Oct 19, 2024

juewuy commented Oct 19, 2024

bsdcpp commented Oct 19, 2024

bsdcpp commented Oct 19, 2024

juewuy commented Oct 19, 2024

bsdcpp commented Oct 19, 2024

juewuy commented Oct 19, 2024

bsdcpp commented Oct 19, 2024

bsdcpp commented Oct 19, 2024 •

edited

Loading

juewuy commented Oct 19, 2024

bsdcpp commented Oct 19, 2024

juewuy commented Oct 19, 2024

juewuy commented Oct 19, 2024

bsdcpp commented Oct 19, 2024

bsdcpp commented Oct 19, 2024 •

edited

Loading

[Bug] immortalwrt 23.05 默认配置，开启白名单后路由器本身无法上网，外网也连不进来 #797

[Bug] immortalwrt 23.05 默认配置，开启白名单后路由器本身无法上网，外网也连不进来 #797

Comments

bsdcpp commented Oct 16, 2024 • edited Loading

Verify steps

Description

juewuy commented Oct 16, 2024

bsdcpp commented Oct 16, 2024 • edited Loading

juewuy commented Oct 16, 2024

bsdcpp commented Oct 16, 2024

juewuy commented Oct 16, 2024

juewuy commented Oct 16, 2024

bsdcpp commented Oct 16, 2024

bsdcpp commented Oct 16, 2024 • edited Loading

pleasant98 commented Oct 17, 2024

bsdcpp commented Oct 17, 2024

juewuy commented Oct 19, 2024

juewuy commented Oct 19, 2024

bsdcpp commented Oct 19, 2024 • edited Loading

juewuy commented Oct 19, 2024

bsdcpp commented Oct 19, 2024 • edited Loading

juewuy commented Oct 19, 2024

bsdcpp commented Oct 19, 2024

juewuy commented Oct 19, 2024

bsdcpp commented Oct 19, 2024

bsdcpp commented Oct 19, 2024

juewuy commented Oct 19, 2024

bsdcpp commented Oct 19, 2024

juewuy commented Oct 19, 2024

bsdcpp commented Oct 19, 2024

bsdcpp commented Oct 19, 2024 • edited Loading

juewuy commented Oct 19, 2024

bsdcpp commented Oct 19, 2024

juewuy commented Oct 19, 2024

juewuy commented Oct 19, 2024

bsdcpp commented Oct 19, 2024

bsdcpp commented Oct 19, 2024 • edited Loading

bsdcpp commented Oct 16, 2024 •

edited

Loading

bsdcpp commented Oct 16, 2024 •

edited

Loading

bsdcpp commented Oct 16, 2024 •

edited

Loading

bsdcpp commented Oct 19, 2024 •

edited

Loading

bsdcpp commented Oct 19, 2024 •

edited

Loading

bsdcpp commented Oct 19, 2024 •

edited

Loading

bsdcpp commented Oct 19, 2024 •

edited

Loading