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.

Sign up for GitHub

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

Jump to bottom

Can't use openvpn tunnel to scan #5183

Closed
TiregeRRR opened this issue May 14, 2024 · 3 comments · Fixed by #5186
Closed

Can't use openvpn tunnel to scan #5183

TiregeRRR opened this issue May 14, 2024 · 3 comments · Fixed by #5186
Assignees
@Mzack9999
Labels
Type: Bug Inconsistencies or issues which will cause an issue or problem for users or implementors.
Milestone
nuclei v3.2.8

Comments

@TiregeRRR
Copy link

TiregeRRR commented May 14, 2024 •
edited

Nuclei version: v3.2.7

Current Behavior:

I'm creating a tunnel interface from openvpn config with route-nopull option specified. After running nuclei with this command:
nuclei -t ~/nuclei-templates/network/detection/pgsql-detect.yaml -i test0 -u ip:port -j -vv -stats -debug and long wait, get this error:
[WRN] [pgsql-detect] Could not make network request for (ip:port) : could not connect to server: [:RUNTIME] ztls fallback failed <- dial tcp my_ip:0->ip:port: connect: connection timed out
Although scanning without interface specified will result in psgql detection

Expected Behavior:

Getting same result as scanning without tun interface

Steps To Reproduce:

  1. Create openvpn tun interface from config with route-nopull option specified
  2. After that run nuclei -t ~/nuclei-templates/network/detection/pgsql-detect.yaml -i test0 -u ip:port -j -vv -stats -debug
  3. Will result in mentioned error

Anything else:

Specifying resolve conf or -sr flag doesn't help
Thanks for any help
@TiregeRRR TiregeRRR added the Type: Bug Inconsistencies or issues which will cause an issue or problem for users or implementors. label May 14, 2024
@Mzack9999
Copy link
Member

@TiregeRRR Just to exclude connectivity/routing issues, would it be possible to check if nmap/ncat with connect scan can reach the target through the tun interface?

$ sudo -u nonrootuser nmap -e test0 scanme.sh -p 80 -vvv

@TiregeRRR
Copy link
Author

@Mzack9999 Surely,

nmap -e test0 target_ip -p 5432 -vvv
Starting Nmap 7.94 ( https://nmap.org ) at 2024-05-15 08:49 UTC
Initiating Ping Scan at 08:49
Scanning target_ip [4 ports]
Completed Ping Scan at 08:49, 0.22s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 08:49
Completed Parallel DNS resolution of 1 host. at 08:49, 13.00s elapsed
DNS resolution of 1 IPs took 13.00s. Mode: Async [#: 1, OK: 0, NX: 0, DR: 1, SF: 0, TR: 3, CN: 0]
Initiating SYN Stealth Scan at 08:49
Scanning target_ip [1 port]
Discovered open port 5432/tcp on target_ip
Completed SYN Stealth Scan at 08:49, 0.23s elapsed (1 total ports)
Nmap scan report for target_ip
Host is up, received echo-reply ttl 49 (0.20s latency).
Scanned at 2024-05-15 08:49:15 UTC for 0s

PORT     STATE SERVICE    REASON
5432/tcp open  postgresql syn-ack ttl 47

Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 13.56 seconds
           Raw packets sent: 5 (196B) | Rcvd: 2 (72B)

@Mzack9999 Mzack9999 mentioned this issue May 15, 2024
Merged
4 tasks
@Mzack9999 Mzack9999 self-assigned this May 15, 2024
@Mzack9999
Copy link
Member

@TiregeRRR I was able to reproduce the issue in case a network interface has multiple address with the relevant ones being first in the list, and I believe the issue is related to a bug in the ip selection logic that instead at the first one, iterated till the end. This should be fixed with #5186

Along with the interface you can also override the souce ip with the one of the interface directly with -sip xxx.xxx.xxx.xxx with (xxx.xxx.xxx.xxx being client assigned by the openvpn server)

@ehsandeep ehsandeep added this to the nuclei v3.2.8 milestone May 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@Mzack9999 Mzack9999

Labels
Type: Bug Inconsistencies or issues which will cause an issue or problem for users or implementors.
Projects
None yet
Milestone
nuclei v3.2.8
Development

Successfully merging a pull request may close this issue.

Select network interface first address projectdiscovery/nuclei
3 participants
@ehsandeep @Mzack9999 @TiregeRRR