Awesome. You are not running into the same issue that I did which is good. I am also a bit fuzzy on the PF_Ring interaction as well, but I have it enabled also and still got bit by rpf.....
I see you ran netcat on port 2055, I think we got our wires crossed on what port you were using. I see from the tcpdump that you are using 9991 for flow data. What do you see if you stop nprobe/ntopng, run 'netcat -lu 9991 | hexdump -C' ? This should confirm that the flow-data is actually making it through any filtering such as iptables/ufw. Erik On Tue, Dec 22, 2015 at 12:33 AM, Yasser Slarmie <[email protected]> wrote: > Hi Erik, > > The server has only 1 nic and a single default-gateway and there is IP > reachability between the netflow exporter and collector. I turned rpf off, > just for the sake of argument, but I still don't see the packets passing > the kernel. > > PF_Ring is enabled, but I don't know enough about it to say whether the > packets will bypass the kernel or not.. > > ~$ netstat -rn > Kernel IP routing table > Destination Gateway Genmask Flags MSS Window irtt > Iface > 0.0.0.0 137.158.154.1 0.0.0.0 UG 0 0 0 > eth0 > 137.158.154.0 0.0.0.0 255.255.255.0 U 0 0 0 > eth0 > > > > root@devubunfl001:~# cat /proc/sys/net/ipv4/conf/eth0/rp_filter > 1 > root@devubunfl001:~# echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter > root@devubunfl001:~# cat /proc/sys/net/ipv4/conf/eth0/rp_filter > 0 > > > root@devubunfl001:~# netcat -lU 2055 | hexdump -C > ^C > > > > root@devubunfl001:~# ufw status > Status: active > > To Action From > -- ------ ---- > 9991/udp ALLOW Anywhere > 22 ALLOW Anywhere > 80/tcp ALLOW Anywhere > 123 ALLOW Anywhere > 3000/tcp ALLOW Anywhere > 2055/tcp ALLOW Anywhere > 9991/udp (v6) ALLOW Anywhere (v6) > 22 (v6) ALLOW Anywhere (v6) > 80/tcp (v6) ALLOW Anywhere (v6) > 123 (v6) ALLOW Anywhere (v6) > 3000/tcp (v6) ALLOW Anywhere (v6) > 2055/tcp (v6) ALLOW Anywhere (v6) > > > > root@devubunfl001:~# tcpdump -n host 137.158.248.10 > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes > 08:15:53.230349 IP 137.158.248.10.32773 > 137.158.154.30.9991: UDP, length > 1320 > 08:15:55.232036 IP 137.158.248.10.32773 > 137.158.154.30.9991: UDP, length > 816 > 08:16:08.229221 IP 137.158.248.10.32773 > 137.158.154.30.9991: UDP, length > 456 > 08:16:11.229323 IP 137.158.248.10.32773 > 137.158.154.30.9991: UDP, length > 744 > 08:16:12.228999 IP 137.158.248.10.32773 > 137.158.154.30.9991: UDP, length > 168 > 08:16:13.229034 IP 137.158.248.10.32773 > 137.158.154.30.9991: UDP, length > 456 > ^C > 6 packets captured > 7 packets received by filter > 0 packets dropped by kernel > > > > ------------------------------ > Date: Mon, 21 Dec 2015 16:09:52 -0600 > From: [email protected] > > To: [email protected] > Subject: Re: [Ntop-misc] nprobe + ntopng WLAN fields query > > Exactly what I am referring to. Your plight sounds exactly like mine as I > just got bit by this and wasted Luca and crew's time sorting it out. Ubuntu > runs RPF check in the kernel and if the Netflow traffic arrives on an > interface that doesn't have a route back to the source via the interface it > was received on, the kernel rejects it. > > You can verify by running netcat -lu 2055 | hexdump -C after starting the > netflow feed from the router. > > Tcpdump runs at the interface pre RPF check, Netcat will bind to the port > and tell you if the kernel passed the traffic. If you do not see traffic > data, it's being dropped before nProbe can capture it. > > > > On Mon, Dec 21, 2015 at 3:54 PM, Yasser Slarmie <[email protected]> > wrote: > > Ntop and nprobe are on the same server. Are you perhaps alluding to urpf > that may be breaking things? The netflow packets arrive on the server, so I > believe nprobe should be able to interpret it without any routing back to > the source or requiring to do so. > > Sent from my Windows Phone > ------------------------------ > From: Erik Schmersal <[email protected]> > Sent: 2015-12-21 07:37 PM > > To: [email protected] > Subject: Re: [Ntop-misc] nprobe + ntopng WLAN fields query > > Is netflow being received on the same interface where Ubuntu's default > route pointing out of? Or is the route back to the flow source pointing out > the same interface that the flows are coming in on? > > On Mon, Dec 21, 2015 at 9:24 AM, Yasser Slarmie <[email protected]> > wrote: > > Hi Eric, > > My commands are: > > ntopng -i tcp://127.0.0.1:2055 & > > nprobe --zmq "tcp://127.0.0.1:2055" --collector-port 9991 -i none -n none > -b 1 & > > Regards, > Yasser > > ------------------------------ > From: [email protected] > Date: Mon, 21 Dec 2015 07:59:00 -0600 > To: [email protected] > Subject: Re: [Ntop-misc] nprobe + ntopng WLAN fields query > > > Can you post your nProbe and nTop commands? > > On Dec 21, 2015, at 03:29, Yasser Slarmie <[email protected]> wrote: > > Hello guys, > > I don't know how to bottom-post on a thread from April 2015, but the above > subject line is still the same. > > I'm implementing ntopng and nprobe for a University (so professional > license is installed and working) and they want to test it specifically for > netflow exports coming from their 6 Cisco Wireless LAN Controllers. > > I have ntopng and nprobe setup but the GUI doesn't interpret any of the > received netflow data. The packets do arrive on the Ubuntu server though. > As a test, I exported traffic from their Cisco 6500 switch, and the GUI > displays the data correctly. > > I took a pcap dump of the received WLC traffic. It's available here: > http://1drv.ms/1mf2iuC > > Could someone please help with what I should do to get the data to display? > > Kind regards, > Yasser > > > _______________________________________________ > Ntop-misc mailing list > [email protected] > http://listgateway.unipi.it/mailman/listinfo/ntop-misc > > > _______________________________________________ Ntop-misc mailing list > [email protected] > http://listgateway.unipi.it/mailman/listinfo/ntop-misc > > _______________________________________________ > Ntop-misc mailing list > [email protected] > http://listgateway.unipi.it/mailman/listinfo/ntop-misc > > > > _______________________________________________ > Ntop-misc mailing list > [email protected] > http://listgateway.unipi.it/mailman/listinfo/ntop-misc > > > > _______________________________________________ Ntop-misc mailing list > [email protected] > http://listgateway.unipi.it/mailman/listinfo/ntop-misc > > _______________________________________________ > Ntop-misc mailing list > [email protected] > http://listgateway.unipi.it/mailman/listinfo/ntop-misc >
_______________________________________________ Ntop-misc mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop-misc
