SNMP through Netscreen VPN

David Klein dklein at NETSCREEN.COM
Sat Apr 21 17:38:09 EDT 2001


This solution can be utilized for sending syslog, e-mail logs, SNMP, and
pings generated from one Netscreen through a tunnel to the remote LAN behind
another netscreen.

When a packet, that is created by a Netscreen, leaves the Netscreen it is
sourced with the IP address of the egress interface.  Therefore, a packet
created by a Netscreen being routed out the untrust interface will be
sourced with the IP address of the Untrusted Port.  When the destination is
the remote LAN through the VPN tunnel, the Netscreen's packet will not go
through the tunnel.

As an example, use the following network:

10.1.0.0/16
  |
NS north (untrust 1.1.1.1)
  |
 (internet)
  |
NS south (untrust 2.2.2.2)
  |
10.2.0.0/16

Let's assume we are looking at the "NS south" netscreen.  Then you've got
some policy for the VPN that looks like:

set policy outgoing "10.2.0.0/16" "10.1.0.0/16" "ANY" Encrypt vpn-tunnel
"VPN-to-North"

The Untrusted IP of 2.2.2.2 is not a part of "10.2.0.0/16" address block.
Therefore you must do the following on the southern Netscreen to correct the
problem:

1.  Create an entry for the Untrusted IP in the Trust side of the Address
book.  For example, call it "Untrusted Port".  This will make this address
available for selection in the Source pull down menu for the Outgoing
policies:
	set address trust "Untrusted Port" 2.2.2.2 255.255.255.255

2.  Create a policy like the following:

set policy outgoing "Untrusted Port" "10.1.0.0/16" "ANY" Encrypt vpn-tunnel
"VPN-to-North"

This completes one side of the problem.  Basically, this policy will allow
anything with a source IP of the Untrusted Port on the southern NS to send a
packet to a destination address of anything on the Northern LAN to be passed
through the tunnel.  However, the packet will get to the desired host on the
other side of the tunnel but the return packet will not get back, because
the remote (or Northern) Netscreen does not have a policy to allow this.
Therefore, you will need to do the following on the northern Netscreen:

1.  So on "NS north" create an Untrusted side address book entry for the
Untrusted Port on the southern Netscreen:
	set address untrust "remote NS untrust" 2.2.2.2 255.255.255.255

2.  Create a policy like the following:

set policy outgoing "10.1.0.0/16" "remote NS untrust" "ANY" Encrypt
vpn-tunnel "VPN-to-South"

Now the Netscreens are configured such that packets that originate from the
southern Netscreen can reach the northern LAN and be returned.  However, if
packets are generated from the northern Netscreen, they will not be able to
reach the southern LAN.  The above process will need to be repeated in
reverse.

Or you can get the latest ScreenOS (version 2.6) where this has all been
fixed.  I.e., a "use VPN" checkbox has been added for each function that
causes the Netscreen to source an IP packet (e.g., email alerts, SNMP,
syslog, etc.).  For ping, use the extended ping.  Just type ping <return>
from the command line and follow the prompts to have the ping sourced from
the internal interface while pinging down a VPN tunnel.

Dave Klein


> -----Original Message-----
> From: Christopher Gripp [mailto:cgripp at AXCELERANT.COM]
> Sent: Friday, April 20, 2001 1:13 PM
> To: VPN at SECURITYFOCUS.COM
> Subject: Re: SNMP through Netscreen VPN
>
>
> -----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
>

VPN is sponsored by SecurityFocus.COM




More information about the VPN mailing list