[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20050217: LDM and Firewall

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: 20050217: LDM and Firewall
  • Date: Thu, 17 Feb 2005 09:37:24 -0700
Waldenio,

>Date: Thu, 17 Feb 2005 14:22:22 -0300
>From: Waldenio Almeida <address@hidden>
>Organization: INPE/CPTEC
>To: Steve Emmerson <address@hidden>
>Subject: Re: 20050217: LDM and Firewall

The above message contained the following:

> Here at cptec whe have 2 networks with LDMs. 
> In the 150.163.141.* the 388 port is free in-out,
> but in 150.163.146.* the ports are free only for 
> out.
> 
> So, a downstream LDM can be behind a firewall,
> where only it will start the connections ?

Yes. The downsteam LDM will connect to port 388 on the upstream computer
to create a TCP connection to the upstream LDM.

> If the upstream starts a connection, the firewall
> block it. will the upstream start any connection ?

Normally, the upstream LDM will not create (start) any connections
(except to its upstream LDM-s, of course).

The ldmsend(1) and ldmping(1) utilities, however, do act like upstream
LDM-s and do create a TCP connection to port 388 on the downstream LDM.
The rpcinfo(1) utility can also be used to connect from an upstream
computer to port 388 on a downstream computer.  If you don't use these
utilities, then it should be OK for the firewall to block packets
destined for port 388 on the 150.163.146.* subnet.

Note, however, that the ldmping(1) and rpcinfo(1) utilities are useful
for troubleshooting an LDM network.  Also, the LDM has proven itself to
be very secure: I know of no instance where an LDM listening on port 388
was used to hack-into a computer.  So the firewall could safely allow 
packets destined for port 388 on the 150.163.146.* subnet.

OK?

Regards,
Steve Emmerson