Discussion:
Not able Work with VPN connection.
Arun Adikesavan -X (aadikesa - IBM - INS at Cisco)
2009-05-27 17:25:09 UTC
Permalink
Hi,

I am using Zenmap 4.62 frequently for resolving port's opened on server
. My job is to troubleshoot with ACL and providing need access for
user. Using Zenmap is one of my troubleshooting method.



Facing a issue with VPN login. Getting following error message





Using Cisco System VPN client Version 5.0.05 (new version).



Looking forward for a solution or suggestion.



Regards,

ARUN
Brandon Enright
2009-05-27 21:28:53 UTC
Permalink
On Wed, 27 May 2009 22:55:09 +0530
"Arun Adikesavan -X (aadikesa - IBM - INS at Cisco)"
Post by Arun Adikesavan -X (aadikesa - IBM - INS at Cisco)
Hi,
I am using Zenmap 4.62 frequently for resolving port's opened on
server . My job is to troubleshoot with ACL and providing need
access for user. Using Zenmap is one of my troubleshooting method.
Facing a issue with VPN login. Getting following error message
Using Cisco System VPN client Version 5.0.05 (new version).
Looking forward for a solution or suggestion.
Regards,
ARUN
I'm sure others will have better suggestions but it looks like the
command you are using is:

$ nmap -T4 -n -v mmx-dev-1

If you add -sC and/or --unprivileged to your options the scan may start
working:

$ nmap -T4 -n -v -sC --unprivileged mmx-dev-1.cisco.com

You'll be pleased to know that troubleshooting ACLs is one of the (many)
design goals of nping which is being worked on this summer.

Brandon
Brandon Enright
2009-05-27 21:30:31 UTC
Permalink
On Wed, 27 May 2009 21:28:53 +0000
Post by Brandon Enright
If you add -sC and/or --unprivileged to your options the scan may
$ nmap -T4 -n -v -sC --unprivileged mmx-dev-1.cisco.com
Oops, I meant -sT, not -sC. Sorry. I think of *C*onnect, not *T*CP or
socke*T*.

You want:

$ nmap -T4 -n -v -sT --unprivileged mmx-dev-1.cisco.com


Brandon
DePriest, Jason R.
2009-05-27 22:30:17 UTC
Permalink
Never mind. I was leaving off '--unprivileged' which, after adding it
seems to work just fine.

Incidentally, adding '--unprivileged' to my ping scan gets it to work, too.

-Jason
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 27 May 2009 21:28:53 +0000
Post by Brandon Enright
If you add -sC and/or --unprivileged to your options the scan may
$ nmap -T4 -n -v -sC --unprivileged mmx-dev-1.cisco.com
Oops, I meant -sT, not -sC.  Sorry. I think of *C*onnect, not *T*CP or
socke*T*.
$ nmap -T4 -n -v -sT --unprivileged mmx-dev-1.cisco.com
Brandon
Arun Adikesavan -X (aadikesa - IBM - INS at Cisco)
2009-05-28 03:32:06 UTC
Permalink
Thanks Brandon it works...

Regards,
ARUN

-----Original Message-----
From: Brandon Enright [mailto:***@ucsd.edu]
Sent: Thursday, May 28, 2009 3:01 AM
To: Arun Adikesavan -X (aadikesa - IBM - INS at Cisco)
Cc: nmap-***@insecure.org; ***@ucsd.edu
Subject: Re: Not able Work with VPN connection.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 27 May 2009 21:28:53 +0000
Post by Brandon Enright
If you add -sC and/or --unprivileged to your options the scan may
$ nmap -T4 -n -v -sC --unprivileged mmx-dev-1.cisco.com
Oops, I meant -sT, not -sC. Sorry. I think of *C*onnect, not *T*CP or
socke*T*.

You want:

$ nmap -T4 -n -v -sT --unprivileged mmx-dev-1.cisco.com


Brandon
DePriest, Jason R.
2009-05-27 22:26:25 UTC
Permalink
I have the same problem when trying to use nmap through a Juniper VPN
tunnel. They are both IPSec and I'm pretty sure they both create a
virtual adapter.

If it matters, my SA ends up with AES/SHA1 for encryption / integrity
in ESP transport mode and LZO is used for compression. I don't manage
the box, but it probably uses DH key exchange to set up the SAs. I
never had to enter a pre-shared key. It does that stuff via an SSL
web page (I think) before handing it off to the VPN client, proper.

It creates a 'Juniper Network Connect Virtual Adapter' that doesn't
show up in ipconfig or the Network Connections Control Panel applet.

I'll try out Brandon's suggestion, too and see what comes out of it.

Tried it. Didn't work.

A debug shows that an ARP from my system is failing.

ARP who-has {VPN Client IP} tell {VPN Client IP}

which doesn't make sense. I am trying to get my own MAC via an ARP and failing.

What format do you use to force something through a particular interface?

I tried using
-e "Juniper Network Connect Virtual Adapter"
-e 3 (after using windump -D to find out what order they were in)
-e \Device\NPF_{C44E890A-E2FC-4DE4-A55A-FBB83C45F2C5}
and they all fail.

-Jason


On Wed, May 27, 2009 at 6:25 PM, Arun Adikesavan -X (aadikesa - IBM -
Post by Arun Adikesavan -X (aadikesa - IBM - INS at Cisco)
Hi,
I am using Zenmap 4.62 frequently for resolving port's opened on server
.  My job is to troubleshoot  with ACL and providing need access for
user. Using Zenmap is one of my troubleshooting method.
Facing a issue with VPN login. Getting following error message
Using Cisco System VPN client Version 5.0.05 (new version).
Looking forward for a solution or suggestion.
Regards,
ARUN
Brandon Enright
2009-05-27 22:31:25 UTC
Permalink
On Wed, 27 May 2009 23:26:25 +0100
"DePriest, Jason R." <***@gmail.com> wrote:
....
Post by DePriest, Jason R.
I'll try out Brandon's suggestion, too and see what comes out of it.
Tried it. Didn't work.
A debug shows that an ARP from my system is failing.
ARP who-has {VPN Client IP} tell {VPN Client IP}
which doesn't make sense. I am trying to get my own MAC via an ARP and failing.
What format do you use to force something through a particular
interface?
I tried using
-e "Juniper Network Connect Virtual Adapter"
-e 3 (after using windump -D to find out what order they were in)
-e \Device\NPF_{C44E890A-E2FC-4DE4-A55A-FBB83C45F2C5}
and they all fail.
For curiosities sake, what happens if you make a static ARP entry for
the target IP with your VPN adaptors MAC? If this helps we might think
about adding a --dest-mac <mac> option.

Brandon
DePriest, Jason R.
2009-05-28 14:44:13 UTC
Permalink
Post by Brandon Enright
For curiosities sake, what happens if you make a static ARP entry for
the target IP with your VPN adaptors MAC?  If this helps we might think
about adding a --dest-mac <mac> option.
Brandon
I tried this out. I have attached the results.

Here is a run down of what I did.

First, I connected to the VPN using the Network Connect Juniper VPN client.

I ran a regular 'ping' against the target IP. It was successful.

I ran an nmap ping scan against the target IP. It failed like this.
SENT (1.5000s) ARP who-has {VPN_Client_IP} tell {VPN_Client_IP}
nexthost: Failed to determine dst MAC address for target {Target_System_IP}
QUITTING!

I created a static arp entry for the target IP using the MAC of the VPN client.

I ran an nmap ping scan against the target IP. It failed in the same
way like this.
SENT (0.7350s) ARP who-has {VPN_Client_IP} tell {VPN_Client_IP}
nexthost: Failed to determine dst MAC address for target {Target_System_IP}
QUITTING!

I deleted the static arp entry for the target IP.

I created a static arp entry for the VPN client IP using the MAC of
the VPN client.

I ran an nmap ping scan against the target IP. It failed in a new and
different way like this.
Host {Target_System_IP} is down.
No data files read.
Note: Host seems down. If it is really up, but blocking our ping probes, try -PN
Nmap done: 1 IP address (0 hosts up) scanned in 3.55 seconds
Raw packets sent: 4 (136B) | Rcvd: 0 (0B)

The attachment has all of the output with sanitized IP addresses.

Thanks.

-Jason

Continue reading on narkive:
Loading...