Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

second network interface on tunnel doesn't correctly see second networks #101

Open
G2G2G2G opened this issue Oct 27, 2021 · 8 comments
Open
Labels
bug Something isn't working

Comments

@G2G2G2G
Copy link

G2G2G2G commented Oct 27, 2021

Thanks for this app it works a lot better than the network discovery on f droid that is like 10 years old. Been using that for a decade lmao, just saw this app. Very fast

If you're connected to a vpn (wireguard on f-droid in my case, to my other office building) I can either tunnel all of my traffic (0.0.0.0/0) in which case my LAN (let's say 192.168.1.0/24) is now not the same (it is now 192.168.2.0/24), (though scanning that interface brings back no results (not an issue)) scanning 0.0.0.0/0 tunnel which is a 10.8.0.2/32 (SO IT THINKS) however it's actually a direct connection to 10.8.0.2/32 which allows full access to LAN 192.168.2.0/24

When you have wireguard NOT tunnel all traffic and instead just have the allowed ips of the 10. and the secondary LAN, Ning should be able to scan both networks. It scan scan it's own network just fine, however when it goes to scan the VPN's network it tries only the 10. instead of also the second 192.168.2.0

I actually think this issue may be a correct method to solve my issue: #3
Instead of having to detect a near infinite LANs (unless that's easy?) I can connect to via wireguard, I can tunnel myself to hundreds of LANs simultaneously (which I do on my desktop for work)

@csicar
Copy link
Owner

csicar commented Oct 28, 2021

Thanks, making a fast and easy network scanner was the goal of Ning. It's nice to see when people feel the same way :)

That seems interesting. Can you post the output of running ip addr show tun0 and ip route in termux and the relevant parts of the wireguard config? (Keep in mind, that especially the wg config contains sensitive information: the private key and public ip of the vpn endpoint)

I think Ning should be able to figure out what subnets are reachable automatically in the future

@csicar csicar added the bug Something isn't working label Oct 28, 2021
@G2G2G2G
Copy link
Author

G2G2G2G commented Oct 28, 2021

So I copied same config on my phone and desktop to see the differences and there are several, especially with ip route
HOWEVER BOTH CAN PING EVERYTHING!
(note the LAN IPs differ from OP (that isn't me making a mistake) because I made up IPs there for an example, but it's very simple setup and identical other than like 2 digits)

Desktop:

ping 192.168.22.1
PING 192.168.22.1 (192.168.22.1) 56(84) bytes of data.
64 bytes from 192.168.22.1: icmp_seq=1 ttl=64 time=0.463 ms
64 bytes from 192.168.22.1: icmp_seq=2 ttl=64 time=0.396 ms

ping 192.168.20.1
PING 192.168.20.1 (192.168.20.1) 56(84) bytes of data.
64 bytes from 192.168.20.1: icmp_seq=1 ttl=63 time=118 ms
64 bytes from 192.168.20.1: icmp_seq=2 ttl=63 time=58.1 ms

ip address show mik
mik: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none 
    inet 10.20.0.2/32 scope global mik
       valid_lft forever preferred_lft forever


ip route
default via 192.168.22.1 dev enp5s0 proto dhcp metric 100 
10.20.0.1 dev mik scope link 
192.168.20.0/24 dev mik scope link 
192.168.22.0/24 dev enp5s0 proto kernel scope link src 192.168.22.20 metric 100 

phone:
(same ping results too hard to copy paste to desktop due to this bug which they don't seem to care to fix termux/termux-packages#992 )

ip address show tun0
37: tun0: <POINTOPOINT,UP,LOWER_UP> mtu 1280 qdisc pfifo_fast state UNKNOWN group default qlen 500
    link/none
    inet 10.20.0.2/32 scope global tun0
       valid_lft forever preferred_lft forever

ip route
192.168.22.0/24 dev wlan0 proto kernel scope link src 192.168.22.228

note the tunnel info differs in some places too not sure what those mean probably android things (also tunnel is named differently (but the config is the same), it is wireguard that does that, no control on name in android it seems)

wireguard config (in this config we communicate with the LAN)
everything is PINGABLE

[Interface]
Address = 10.20.0.2/32
PrivateKey = um980bunm98gn

[Peer]
Endpoint = external_IP:port
PublicKey = 235urw9eifhjsf
AllowedIPs = 10.20.0.1/32, 192.168.20.0/24

Changing the AllowedIPs (0.0.0.0/0) you tunnel all traffic idc if it's pingable there or not (didn't bother testing)

AllowedIPs = 0.0.0.0/0

So I guess in summary, the android ip route is shit and not how wireguard seems to work at least on that platform, there's some hardware accelerated tunneling from what I read online. I am not sure if that's how it does it or what, but that's probably why Ning can't read it.. and I don't really want to tell you to read the wireguard config because that's malicious.. so I thing the IP range search with CIDR is plenty good.

Here's a sloppy diagram just so you can see it is very simple (22.20 is the desktop and 22.228 is the phone, which can scan the x.x.22.x network no problems)
test-fs8

I guess technically the two networks go through the internet and shouldn't have a blue line drawn connecting to each other but too late it's already saved!

@csicar
Copy link
Owner

csicar commented Oct 28, 2021

Wow! I think that is the best error report I ever got :)

So, the output of ip route tells you what interface your system will use for what ips.

Here's the weird thing:
Your computer will send anything to 192.168.20.0/24 through mik, which is the wireguard inferface. (see 192.168.20.0/24 dev mik scope link )
On your phone there is no matching entry. In fact there are also missing entries for your mobile broadband etc. Are you sure those are all the entries?

@G2G2G2G
Copy link
Author

G2G2G2G commented Oct 28, 2021

Yea, I don't have root (on phone) not sure if anything is blocked from ip route seeing.. but I did testing and can always see routes on my desktop regardless if the user is "locked down"... idk about android for sure though

all internet traffic does not touch wireguard at all in the LAN config, only things destined for 192.168.20.0/24 and 10.20.0.1/32 (1 ip there) do (and 10.20.0.2/32 is the device itself)

In the ALL traffic tunnel with 0.0.0.0/0 where ALL traffic is routed through wireguard, it doesn't show up on the phone's ip route at all..
wireguard shows traffic live (so I can easily tell it's being used) and I have verified via web browser at https://ifconfig.me thoroughly.. testing it on/off etc.

I swear years ago I read the hardware acceleration of VPN on phones did weird network stuff but maybe I am confusing it with hardware acceleration of NAT (which doesn't let you monitor traffic on the same device specifically) (also the hotspot is hardware accelerated maybe it was that+natting)

I added a screen so you can be sure I'm not illiterate. This is with 0.0.0.0/0 ALL traffic on all ports goes through it.

1

@G2G2G2G
Copy link
Author

G2G2G2G commented Oct 28, 2021

actually what is this in "ip address"

it has a lot of interfaces
1

So those ones pictured are always there, but there are 38 of them with wireguard on and 24 with it off.

How many does your phone have with no vpn at all? Is that normal?

oh wait I lied there's only the 24+1 but it autoincrements until reboot, so since I keep turning it on/off it is now at 44 instead of 38 lol

@csicar
Copy link
Owner

csicar commented Oct 28, 2021

For future reference, here is my phones output (also using wg)

~ $ ip r
10.10.0.0/24 dev tun0 proto kernel scope link src 10.10.0.8
xxx.xxx.xxx.xxx/30 dev rmnet_data0 proto kernel scope link src xxx.xxx.xxx.134
192.168.0.0/24 dev wlan0 proto kernel scope link src 192.168.0.203

@csicar
Copy link
Owner

csicar commented Oct 28, 2021

I added a screen so you can be sure I'm not illiterate

I'm believing you. It's just super weird why the routes are not shown and means, that Ning needs to use another way of matching interfaces and subnets. That makes finding out what subnets to scan harder. I'll have a look into other ways of mapping from interfaces to subnets

@G2G2G2G
Copy link
Author

G2G2G2G commented Oct 28, 2021

yea those ip address interfaces don't seem to be anything, I thought it was with all the 0.0.0.0 mentions but it doesn't change at all with the allowedips of 192.168.20.0/24 vs 0.0.0.0/0 vs 10.20.0.1/32, 192.168.20.0/24

& yea I understand the ip route thing which is why I settled on being able to type the subnet in, also I think in the case where some subnet is inside of another subnet and that router knows it but maybe your phone doesn't know it (but phone sends it's questions to the router that finds it for him.. normal networking) it's nice to just slap the ip with the whole subnet in

It's very weird, what phone are you on? I just checked an samsung S5, samsung S8 neither has ip route with wireguard at all.. at&t and tmobile respectively
is your phone rooted? I guess it doesn't matter cuz wireguard doesn't need root either

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants