SNMP through Netscreen VPN

[Christopher Gripp]

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

David,
For the trusted network in the policy are you using the default
"Inside Any"  if so I have seen problems with this.  We build out a
trusted network explicitly and then use it in the policy.  I don't
know if this will effect your issue but you could try it.
 
Chris

- -----Original Message-----
From: David Leija [mailto:DLeija at PENSON.COM]
Sent: Thursday, April 19, 2001 8:39 AM
To: VPN at SECURITYFOCUS.COM
Subject: SNMP through Netscreen VPN



Thank you for your detailed explanation and suggestions. I think I've
been 
able to absorb the content in your response. Yet I still can't
initiate 
traffic directly from a Netscreen to a remote LAN IP. Consider the 
following: 

Lan1---NS1------------------------NS2---Lan2 

As you suggested, I have added the untrusted interface IP to the
trusted 
side of the address book. I then created a policy, using the new
address as 
the source, directed such traffic to be encrypted, and use our
existing and 
functional site to site VPN. I performed these steps on both units.
My 
problem remains. From any host on Lan1, other then NS1, I can access
any 
host on Lan2, including NS2. The reverse is also true in that from
any host 
on Lan2 minus NS2, I can access any host on Lan1 including NS1.
However, 
from NS1(telneted to the unit), cannot initiate traffic to any host
on Lan2, 
including the trusted interface of NS2. The reverse is also true
here. From 
NS2 I cannot access any host on Lan1 including the trusted interface
of NS1. 


I believe my problem is for the most part as you described. I think
that 
traffic initiating from a Netscreen uses its untrusted IP as the
source IP 
and then follows it routing rules, sending the packets to whatever
its 
upstream gateway is. I verified this by running 'exec trace-route'
from a 
Netscreen to the remote lan. The output confirms that the packets are
not 
being tunneled but simply routed upstream then lost. 

There must be something in addition to the steps already taken that
is 
needed to permit this type of communication. I've already modified
policy 
orders. Nothing. Do I need a completely separate VPN? Is there some
issue 
that occurs when adding the IP of the untrusted interface to the
trusted 
side of the address book? TIA 

L. David Leija 
Penson Financial Services 
dleija at penson.com 
(214) 765-1228 


>From: Jeff Dell <jdell at TELEPLACE.COM> 
>Reply-To: Jeff Dell <jdell at TELEPLACE.COM> 
>To: VPN at SECURITYFOCUS.COM 
>Subject: Re: SNMP through Netscreen VPN 
>Date: Tue, 10 Apr 2001 07:36:59 -0400 
> 
>When a packet leaves the Netscreen that is not destined for it's
>Trusted or  DMZ LANs the packet leaves the Netscreen with a source
>IP of the Untrusted  Port.  When the destination is the remote LAN
>through the VPN tunnel, the  Netscreen will not go through the
>tunnel, because the VPN policy reads  
> 
>set policy outgoing "Inside Any" "Remote LAN" "ANY" Encrypt
>vpn-tunnel "VPN  to NY" 
> 
>The source address is the problem here.  It reads "Inside Any".  The
> Untrusted Ip is not a part of "Inside Any".  Therefore you must do
>the  following on the local (lets call this the CA Netscreen) to
>correct the  problem. 
> 
>1.  Create an entry for the Untrusted IP in the Trust side of the 
>Address  book .  This will make this address available for selection
>in the Source  pull down menu for the Outgoing policies. 
> 
>2.  Create a policy like the following. 
> 
>set policy outgoing "Untrusted Port" "Remote LAN" "ANY" Encrypt
>vpn-tunnel  "VPN to NY" 
> 
>This completes one side of the problem.  Basically, this policy will
>allow  anything with a source IP of the Untrusted Port and a
>destination port of  anything on the Remote LAN to be passed through
>the tunnel.  The packet  
will 
>get to the desired host on the other side of the tunnel.  However,
>the  packet will not get back, because the remote Netscreen does not
>have a  policy to allow this.  Therefore, we will need to do the
>following on the  remote Netscreen (lets call this the NY
>Netscreen). 
> 
>1.  Create an Untrusted side address book entry for the Untrusted
>Port of  the original CA Netscreen. 
> 
>2.  Create a policy like the following. 
> 
>set policy outgoing "Inside Any" "CA Untrust IP" "ANY" Encrypt
>vpn-tunnel  "VPN to CA" 
> 
>Now the Netscreens are configured such that packets that originate
>from the  CA Netscreen can reach the NY LAN and be returned. 
> 
>Jeff 
> 
>-----Original Message----- 
>From: L. David Leija [ mailto:ldl1971 at HOTMAIL.COM
><mailto:ldl1971 at HOTMAIL.COM> ]  Sent: Monday, April 09, 2001 8:50 PM
>To: VPN at SECURITYFOCUS.COM 
>Subject: SNMP through Netscreen VPN 
> 
> 
>We've deployed 2 Netscreen-10's and successfully established an
>AutoKey  encrypted tunnel between them. We also utilize the
>SNMP/Perl monitoring  software, MRTG. We are able to monitor data
>from the Netscreen on the near  side of the tunnel, however we
>cannot get SNMP to talk to the remote  Netscreen through the tunnel.
>We can ping it fine, we also have complete  access to all resources
>on the remote site through the tunnel. However,  
SNMP 
>always gets "SNMP Error:no response received" when trying to
>establish a  session. Any clues on where the problem is? The VPN
>tunnel, the remote  Netscreen, or MRTG. I don't thinks its MRTG as
>it is currently monitoring  countless other devices successfully. 
> 
>_________________________________________________________________ 
>Get your FREE download of MSN Explorer at http://explorer.msn.com
><http://explorer.msn.com>   
> 
>VPN is sponsored by SecurityFocus.COM 
> 
>VPN is sponsored by SecurityFocus.COM  

VPN is sponsored by SecurityFocus.COM 


-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>

iQA/AwUBOuB7bWLRPLnfp/zREQJfigCffbpHDTG6DajK3kQZwhJukJo9p3AAoKHH
v4vGLjcZHYCFumuJqxM2Jyhy
=AAKt
-----END PGP SIGNATURE-----

VPN is sponsored by SecurityFocus.COM