From owner-freebsd-net@FreeBSD.ORG Tue Jan 18 17:30:33 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 137D016A4CE for ; Tue, 18 Jan 2005 17:30:33 +0000 (GMT) Received: from mail.seekingfire.com (caliban.rospa.ca [24.72.10.209]) by mx1.FreeBSD.org (Postfix) with ESMTP id 79E5D43D45 for ; Tue, 18 Jan 2005 17:30:32 +0000 (GMT) (envelope-from tillman@seekingfire.com) Received: by mail.seekingfire.com (Postfix, from userid 500) id B4FCB10F; Tue, 18 Jan 2005 11:30:31 -0600 (CST) Date: Tue, 18 Jan 2005 11:30:31 -0600 From: Tillman Hodgson To: freebsd-net@freebsd.org Message-ID: <20050118173031.GF80831@seekingfire.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . X-GPG-Key-ID: 828AFC7B X-GPG-Fingerprint: 5584 14BA C9EB 1524 0E68 F543 0F0A 7FBC 828A FC7B X-GPG-Key: http://www.seekingfire.com/personal/gpg_key.asc X-Urban-Legend: There is lots of hidden information in headers X-Tillman-rules: yes he does User-Agent: Mutt/1.5.6i Subject: ng_netflow and tun interfaces, collecting on the same host X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2005 17:30:33 -0000 Howdy folks, I have a small pile of OpenVPN tunnels terminating on a "tunnel router" (FreeBSD -current on sparc64 with 5 hme ethernet interfaces). Tunnels carry general IP and OSPF traffic. They may carry IPv6 in the future, though that's not a necessity. The number of tunnels will grow over time and will likely start to include ipsec as well as the existing openvpn. I'd like to perform netflow monitoring and collection on the box for the individual tunnels. Unfortunately, I'm not only net to netflow in general, all l I know about netgraph I learned from http://www.daemonnews.org/200003/netgraph.html (a fairly old article, too) :-) Taking a look at (and borrowing freely from) http://taosecurity.blogspot.com/2004/01/freebsd-kernel-module-for-generating.html, I see that I can do something like this (using tun0 as an example): kldload ng_ether kldload ng_tee kldload ng_netflow ngctl -f - << EOF mkpeer tun0: tee lower right connect tun0: tun0:lower upper left mkpeer tun0:lower netflow right2left iface0 name em0:lower.right2left netflow msg netflow: setifindex { iface=0 index=1 } mkpeer netflow: ksocket export inet/dgram/udp msg netflow:export conenct inet/127.0.0.1:4800 EOF I'm not sure if ng_ether covers tun interfaces or if it only covers the underlying ethernet interface. I'm also not sure that sending the netflow data to loopback is the most efficient way to get at it with the collector -- on a Cisco router, sending netflow data to a seperate host ameks sense, but it odesn't in my case. Is there a better way to do this? I'm also not sure what the best method is to collect data for multiple tun interfaces. I'm thinking of replicating the above netgraph config, but forwarding to different ports and running multiple collectors. Are there any good resources out there that someone could point me at? Alternatively, does anyone have some time to walk me through it off-list and I'll post a summary to the list afterwards (as well as write an article on it for http://www.seekingfire.com/documents/, since I'm planning on doing that anyway once I get this running nicely). Thanks, -T -- "To enjoy the flavor of life, take big bites. Moderation is for monks." -- Robert Heinlein