3

I am inside an enterprise network, and connecting a P2P VPN to an Azure VPN gateway. With that VPN connection up I can RDP to a jump server.

I want to do a port scan, indicated by the red arrow. The ports should appear to be closed when scanned from any other place than the jump host (due to firewall rules, in Azure - Network Security Group rules).

I want to test that nodes connected to the VPN gateway should be able to reach the jump host, but nothing else. The reason we want to test this is that we are using Azure technology that is new to us (firewall rules implemented by Network Security Groups). It's a proof of concept project.

What I discovered is that I cannot scan these directly with nmap from my local machine, because the VPN is treated like a PPP connection/dialup interface in windows. E.g. see http://seclists.org/nmap-dev/2006/q3/438.

I am looking for input suggestions on how to proceed.

enter image description here

| improve this question | |
  • Maybe this post belongs under network engineering. I am a bit new, can I migrate my post there, or could I simply re-post it there? – BenM Mar 6 '18 at 9:14
  • Honestly i dont see they fixed it ever. Needlesly to ask probably but you cant access the VPN Gateway directly arent you :)? – Adam Sitemap Mar 6 '18 at 9:17
  • Thanks for the graphic! It makes the network much easier to understand. And yes, this is a networking question, not a security question. Do not re-post, let us migrate. – schroeder♦ Mar 6 '18 at 9:17
  • I think google has some alternatives for you already. This might work: nmap.org/nsedoc/scripts/broadcast-pppoe-discover.html – Adam Sitemap Mar 6 '18 at 9:17
  • 1
    @AdamSitemap thanks for the response. From reading the site you provided it seems PPPoE needs an ethernet interface. The problem is that the VPN connection is not, it is a PPP interface. Regarding the VPN gateway, not exactly sure what you ask. But I cannot use the gateway itself to scan, I need to run the test n the actual network topology. – BenM Mar 6 '18 at 9:27
0

I seem to have found a solution. Although it seems Npcap is not fully supporting PPP connections, I was able to use the --unprivileged option, in combination with skipping the ping probe using the -Pn option in nmap. In this case, this seems to suffice for the task I have at hand, although it is not fully clear to me what I might be missing when using the unprivileged mode.

For completeness I am adding the description of these:

--privileged (Assume that the user is fully privileged) Tells Nmap to simply assume that it is privileged enough to perform raw socket sends, packet sniffing, and similar operations that usually require root privileges on Unix systems. By default Nmap quits if such operations are requested but geteuid is not zero. --privileged is useful with Linux kernel capabilities and similar systems that may be configured to allow unprivileged users to perform raw-packet scans. Be sure to provide this option flag before any flags for options that require privileges (SYN scan, OS detection, etc.). The NMAP_PRIVILEGED environment variable may be set as an equivalent alternative to --privileged.

--unprivileged (Assume that the user lacks raw socket privileges) This option is the opposite of --privileged. It tells Nmap to treat the user as lacking network raw socket and sniffing privileges. This is useful for testing, debugging, or when the raw network functionality of your operating system is somehow broken. The NMAP_UNPRIVILEGED environment variable may be set as an equivalent alternative to --unprivileged.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.