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

[NOAAPORT #BGK-918302]: NOAAPort ingest not working

Hi,

Sorry for the tardy reply; several other things came up that needed dealing 
with...

re:
> NB: we have tested but turning of the firewall on the local system because we 
> don’t
> have any firewall setting for the individual interface (em4).

And yet, it appears that something is blocking the flow of UDP packets from the
Novra S300N through your Ethernet interface, em4.

re:
> You are raising very important points here. The way we approached the new 
> configuration
> was to match the legacy. However, since they are running different OS, it was 
> hard to
> make apple to apple comparisons.

Yes, especially since RH 7 is significantly different from older releases!

re:
> On the legacy server my understanding is the following
> line in the iptables is setting the four multicast  ports (1201-1204) on the 
> interface
> eth3 to accept a udp traffic.
> 
> -A RH-Firewall-1-INPUT -d 224.0.1.0/255.255.255.0 -i eth3 -p udp -m state 
> --state NEW -m udp --dport 1201:1204 -j ACCEPT

Since we are using a private Ethernet interface for our NOAAPort ingestion,
we don't have to worry about traffic other than from a Novra S300N arriving
on the Ethernet interface we are using.  Because of this, our IPTABLES 
entry for the interface we are using is very simple:

-A INPUT -i eth1 -j ACCEPT

re:
> In the new servers running redhat 7.6 there are two configuration. The fire 
> wall and the
> iptables routes.

OK.  Is IPTABLES active even tough firewalld is not?

re:
> The following two commands on one of the new servers gives the
> following.
> 
> 1. firewall-cmd --list-all
> 
> Here I don’t see the 1201 to 1204 ports in the list. On the protocols I  only 
> see
> igmp and in the interface I don’t see em4 (which I guess means setting are 
> for all
> interfaces). On the link you provided yesterday, there was a way to create a 
> multicast
> zone (here we have only the public zone) and add new settings accordingly.
> ----------------------------
> 
> public
> target: default
> icmp-block-inversion: no
> interfaces:
> sources:
> services: multicastlistener
> ports: 22/tcp 161/udp 161/tcp 162/udp 162/tcp 383/tcp 9898/tcp 1500/tcp 
> 1500/udp 1501/tcp 1501/udp 1502/tcp 1502/udp 1521/tcp 1521/udp 2049/tcp 
> 2059/tcp 2217-2229/tcp 2300/tcp 2301/tcp 3181/tcp 3182/tcp 4545/tcp 5222/tcp 
> 6767/tcp 6768/tcp 10128/tcp 12346/tcp 80/tcp 388/tcp 388/udp 12345/udp
> protocols: igmp
> masquerade: no
> forward-ports:
> source-ports:
> icmp-blocks:
> rich rules:
> ---------------------------------------

I am not familiar enough with firewalld to be able to comment on this listing.

re:
> 2. iptables-save > iptables06202019 and vi the text file is showing the 
> following
> 
> Here I don’t see the 1201-1204 ports either. Could you please help on how to 
> set
> the multicast ports on the iptables?

Since you said that you are using a private Ethernet interface for your NOAAPort
ingestion why not simply allow all traffic through it in your IPTABLES.  Again,
the way we have configured our IPTABLES on our CentOS 6.10 systems is included
above.


One quick test you could run is to turn off IPTABLES while making
sure firewalld is also off, and then restart your LDM and see if data
gets ingested.  If it does, it means that the culprit is either
your firewall or routing (and the routing we are using was included
in my previous email).


Cheers,

Tom
--
****************************************************************************
Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage                       http://www.unidata.ucar.edu
****************************************************************************


Ticket Details
===================
Ticket ID: BGK-918302
Department: Support NOAAPORT
Priority: Normal
Status: Closed
===================
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata 
inquiry tracking system and then made publicly available through the web.  If 
you do not want to have your interactions made available in this way, you must 
let us know in each email you send to us.