Has anyone considered using IPSEC to create a security association (a la
tunnel) between the Netview server and the router at the MLM/s location?
This way all traffic between the Netview server and the MLM would be
tunnelled/encapsulated through the firewall within either protocol number
50 (Authentication Header) or 51 (Encapsulating Security Payload) depending
on choice of implementation.
This may be more acceptable to the security folk as they can control
traffic to specific IP addresses and protocol numbers. This is not
fool-proof and security of the Netview Server itself becomes important, but
may be an option.
Regards,
David Steed
IBK Pty Ltd
www.ibk.com.au
>Date: Mon, 23 Apr 2001 07:58:42 +0100
>From: Jane Curry <jane.curry@skills-1st.co.uk>
>Subject: Re: MLM's and Firewalls
>
>We have tried this. We wanted both monitoring and discovery through a
>packet-filtering firewall. We hoped to be able to JUST open udp/161 and
>udp/162, and monitor devices using SNMP from NetView and/or using ping
from
>MLM - ie. ping was blocked at the firewall.
>
>Tracing what happened, the MLM discovered devices on its own side of the
>firewall and sent that info to NetView via UDP/161 - OK so far.
>Unfortunately, NetView will not admit thoses devices into the object
database
>until it has succeeded in ping'ing them (which it cannot do). We watched
the
>MLM-discovered devices just going further down the NetView ping-poll
queue.
>
>So, the answer to your question if you want status and discovery, is that
you
>need to open the SNMP ports (with unrestricted high port access for the
>"source" port), AND ping.
>
>Anyone else with experience in this area - I'd love to share stories. MLM
>seems like the right architectural solution to solve many of these
firewall
>issues, but it's not quite there yet....
>
>Cheers,
|