I have one router that i poll for SNMP data that is on the other side of a
linux box that is doing masquerading (many->1 NAT) and I have not had any
problems.
David Lang
On Tue, 21 Sep 1999 [EMAIL PROTECTED] wrote:
> Date: Tue, 21 Sep 1999 09:39:31 +0800
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: Network Management through a firewall
>
> Firstly, my applologies for the brain-dead quoting - I am using Lotus
> notes.
>
> RE: SNMP through a NAT firewall.
>
> Unfortunately, SNMP encodes the interface addresses in the body of the SNMP
> packet. While this _CAN_ be translated with Payload Address Translation
> (PAT) I have not been able to find a single commercial (or
> freeware/shareware) solution that is capable of providing PAT accross
> wide-ranging MIBs.
>
> When we asked the vendors, HP, IBM, etc... all said "Yep we can work in
> that situation".
> Unfortunately, this was more a sales than technical response.
>
> We did get NAT working onto our translated networks, using either of two
> solutions:
> 1) The KLUDGE:
> ~~~~~~~~~~~
> 1.1) Each Managed-Host on the internal network was assigned an IP-Alias on
> a routable network.
> 1.2) The High-Level-Manager was told how to route to this network.
> 1.3) The Managed-Host re-registered itself with the high-level-manager (at
> each boot) with the routable address.
>
> Advantage: No additional hardware.
> Advantage: It works (Only just, but it does work!).
> Advantage: Set it & forget it.
> Disadvantage: You can't do this with routers.
> Disadvantage: You can't auto-discover.
> Disadvantage: It breaks some extended functionality
> Disadvantage: Don't renumber your hosts. (but then again, don't renumber
> when using SNMP management anyway!)
>
> 2) The $work$a$round$
> 2.1) Buy a mid-level-manager
> 2.2) Put this machine inside the translated network.
>
> Advantage: Everything works.
> Advantage: Less WAN management traffic to the HLM
> Disadvantage: $cost$. (This can be very significant with small clients, as
> the MLM may cost more than the rest of the service put together.)
> Disadvantage: Increased configuration required to setup multiple MLMs.
> Disadvantage: Need to administrate a (selection of) Mid-Level-Manager(s).
>
>
>
>
> To: [EMAIL PROTECTED]
> cc: (bcc: Crispin Harris/GECITS-AP)
> Subject: Network Management through a firewall
>
>
>
>
> Does anyone out there know if its possible to manage devices in a private
> network using SNMP through a firewall configured to do address translation
> (NAT)? The scenario is this...
>
> The Network Management Stations (NMS) are in a centralized NOC. They
> running HP Openview, Concord and Ciscoworks 2K on Sun/Solaris 2.6 It
> manages
> devices in multiple locations that have their own routed networks.. much
> like
> an ISP would. One of these locations has a private (10.x.x.x) network
> addressing scheme and uses NAT in their firewall (Border Manager) to
> translate private addresses to public ones.
>
> The problem is that when the NMS does an SNMP get on the public (NAT'd)
> address (i.e. belonging to a router), the SNMP reply contains the Mib
> object
> (ifAddress) of the physical interface which is a 10.x.x.x address. When a
> ping/subsequent poll of the device occurs it pings the address of the
> physical interface, rather than the public address. Of course there will
> be
> no reply from the private (10 network) address-- the firewall will discard
> ICMP requests to private addresses.
>
> My question is-- does anyone know of a way to get the firewall, or even a
> router, translate the private IP address in the SNMP reply (ifAddress) to
> the
> NAT'd address? Or of another work around that wont be a maintenance
> nightmare?
>
> Thanks,
>
> C. Mayfield
> -
> [To unsubscribe, send mail to [EMAIL PROTECTED] with
> "unsubscribe firewalls" in the body of the message.]
>
>
>
>
>
>
>
> GE Capital IT Solutions
> This email is confidential. If you are not the intended recipient, you must
> not disclose or use the information contained in it. If you have received
> this mail in error, please tell us immediately by return email and delete
> the document.
>
>
> -
> [To unsubscribe, send mail to [EMAIL PROTECTED] with
> "unsubscribe firewalls" in the body of the message.]
>
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
