Kyjiep
Regular Contributor
The tun interface is not used to access the proxy server. Simply after adding the proxy server settings to the sing-box configuration file and after rebooting it, sing-box starts listening to the port specified in the proxy server settings, working as a regular proxy server. The tun interface does not even need to be specified in the configuration file, proxy servers do not interact with it in any way. We need to somehow understand where exactly the traffic addressed to local resources goes from sing-box. In my configuration file, it is specified that it should go to direct. This means that it will not be routed to any of the proxy tunnels specified in the configuration file. Where exactly it goes on the router is not clear to me. Although, perhaps, this is not particularly important. Traffic to external sites comes from the external IP address of the router, which means that from sing-box it goes to direct, and not to tunnels. Here are my routing rules:Assuming data goes from your client over wan to sinbox sbtun interface onwards to wan it will be subject of MASQUARADE when leaving the router wan interface which is why it appears to come from your router wan ip externally. But internally, what address would data appear to come from?
Are routes set up for this ip to go to sbtun interface. If your clients use policy route tables, are these routes present there as well?
Firewall issues, are proper firewall routes in place on the router to allow new connections to be made from sbtun to br0 interface?
Are lan client own firewall accepting incoming connections from sbtun address range?
Code:
0: from all lookup local
78: from 192.168.50.52 lookup main
79: from 192.168.50.51 lookup main
80: from 192.168.50.50 lookup main
81: from 192.168.50.46 lookup main
82: from 192.168.50.41 lookup main
83: from 192.168.50.37 lookup main
84: from 192.168.50.36 lookup main
85: from 192.168.50.35 lookup main
86: from 192.168.50.34 lookup main
87: from 192.168.50.30 lookup main
88: from 192.168.50.1 lookup main
89: from 192.168.50.0/24 lookup 5553
90: from all to 10.6.0.2 lookup main
90: from all to 10.6.0.3 lookup main
90: from all to 10.6.0.4 lookup main
90: from all to 10.6.0.5 lookup main
90: from all to 10.6.0.6 lookup main
90: from all to 10.6.0.7 lookup main
32766: from all lookup main
32767: from all lookup default
Code:
default dev sbtun scope link
10.6.0.2 dev wgs1 scope link
10.6.0.3 dev wgs1 scope link
10.6.0.4 dev wgs1 scope link
10.6.0.5 dev wgs1 scope link
10.6.0.6 dev wgs1 scope link
10.6.0.7 dev wgs1 scope link
95.165.64.1 dev ppp0 proto kernel scope link
127.0.0.0/8 dev lo scope link
169.254.0.0/16 dev eth0 proto kernel scope link src 169.254.251.191
172.19.0.0/28 dev sbtun proto kernel scope link src 172.19.0.1
192.168.50.0/24 dev br0 proto kernel scope link src 192.168.50.1
I noticed that for the built-in wireguard server in the nat table there is a rule
Code:
-A LOCALSRV -p udp -m udp --dport <wireguard_server_port> -j ACCEPT
I believe that another problem I wrote about earlier has the same cause https://www.snbforums.com/threads/s...outers-with-merlin-firmware.90762/post-918618
Last edited: