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
Scanning network from Wireguard tunnel results in "expression rejects all packets" yet local network scan works without issue #640
Comments
Is this the same issue as #578? If a Wireguard tunnel reports an NdisMedium type that libpcap's pcap-npf maps to a DLT_ type that the libpcap pcap compiler doesn't fully support, that's an error message that you might get from the pcap compiler. |
And what was the filter expression? If, as per my guess in #578, a Wireguard interface has NDIS type If, for example, I run the command
where raw-ip-capture.pcap is a file with a link-layer type of
I get
That happens to e on macOS, with a capture made on an unknown system, but the same behavior will occur with a capture on a |
And what is the tool you're using for "scanning"? In Nmap issue #nmap/nmap#2381, it says nmap should "verify that the pcap_datalink() type supports ARP before using ARP scan for host discovery on that link"; if the link-layer type of a Wireguard tunnel is |
I have no idea how I could check the if this is the same value that is in the oem23.inf that is liked in properties of network controler, then its:
I was reffering to
Do I understand correctly that for now I cannot use nmap for wireguard tunnels ? edit: I tried with |
Yup, that means "packets that begin with an IP header", so it's mapped to
That's the argument to nmap, not a filter expression generated by nmap. That's a question that would have to be answered by an nmap developer, perhaps by an nmap developer changing nmap to report the generated filter when
The "workaround" is
If you were to try to capture on the Wireguard interface with a filter expression such as "arp", or "ether host XXX", or "ether proto 0x0806', or..., you'd get an error.
Only if...
...there's a way to get nmap not to try to use any filter of the aforementioned sort on that interface. Note that this is neither WinPcap/Npcap-specific nor Windows-specific:
This is on macOS, but you'll get the same results (modulo the particular error message) on any other 4.4-Lite-derived OS, as the loopback interface on those OSes does not have a link-layer type that provides an Ethernet header. On Linux, it does, but unless your software is never ever ever going to run on anything other than Linux, you should not rely on the loopback interface providing an Ethernet header when you capture on it. |
It would be best if nmap would avoid doing anything involving MAC addresses - including assuming that a network has MAC addresses and that "ether host"/"ether src"/"ether dst" will work - or packet types other than IPv4 and IPv6, on any link-layer header types other than:
|
@guyharris that is a lot of wisdom you put on me, thank you very much. So If I understand correctly the current situation is to wait for/write code that would disable any ARP related actions in nmap. ( I was hoping that Maybe a bad assumption about higher layer is using valid lower layer or maybe technology and non-standard solution (or future standard) went to much ahead of nmap development 👍 |
Or whatever it is that's causing nmap to generate a filter of some sort that isn't supported for packets that begin with an IP header; from a quick look at the code it appears that nmap may do IPv6 Neighbor Discovery and have a capture filter that checks for some multicast MAC address, but there isn't any MAC address in |
Describe the bug
I'm trying to scan network that is on the other side of wireguard tunnel. That will results in:
Error compiling our pcap filter: expression rejects all packets
. Scaning with same setup my local network is working correct.To Reproduce
Steps to reproduce the behavior:
Error compiling our pcap filter: expression rejects all packets
.Expected behavior
I should be able to scan host on other side of Wireguard tunnel
Diagnostic information
Additional context
The text was updated successfully, but these errors were encountered: