From owner-svn-src-all@FreeBSD.ORG Mon Jan 26 22:17:58 2015 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 84375A4C; Mon, 26 Jan 2015 22:17:58 +0000 (UTC) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0DA6F9B1; Mon, 26 Jan 2015 22:17:58 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id em10so9702725wid.1; Mon, 26 Jan 2015 14:17:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=CnV1AEeqTqd+QHOfYZPyaOEk0SepgfNnuOaqBUW0Kjg=; b=IqxwRDJ+wPFCh5HxN7BC1b2gJuw0WSMXDjsALffvPr9eTR29N0qs0VMHwb82CEQvmN fLfpadGd1vdBBS/hE28leKfzLoR6CT1VZ4k1laXRhszvytlusMqRCEuF0vfVCzALl2mp wbXkCTMxkgWiwZdQVRsFA5LVPbRV2fiP4g5ekyr7ZNkjiyX5+k7s6PcmkCLFRX4n4jmV 2bvjtKX8qSQdae09R/oBWyf/i26sdGuAkXkdIHyHU/CYDTumBP/SLBZ8pOddVl/ncvAe BPpz/0nlZuWLoEm0N5JwVpsC404WArKGXCfzMi+/3sQ9+WI6/1gZz5MKmTmmTdVAclcs CsFA== X-Received: by 10.180.76.72 with SMTP id i8mr858407wiw.22.1422310676301; Mon, 26 Jan 2015 14:17:56 -0800 (PST) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.194.61.1 with HTTP; Mon, 26 Jan 2015 14:17:35 -0800 (PST) In-Reply-To: <163C05D4-6893-47A2-B427-F482A59E8FE5@van-laarhoven.org> References: <201501252037.t0PKbXNW070662@svn.freebsd.org> <2669297.0BvAQ4C19U@ralph.baldwin.cx> <163C05D4-6893-47A2-B427-F482A59E8FE5@van-laarhoven.org> From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Mon, 26 Jan 2015 23:17:35 +0100 X-Google-Sender-Auth: jBawVRTSgTuJCbo__xKRZGwQOLQ Message-ID: Subject: Re: svn commit: r277714 - head/sbin/ipfw To: Nick Hibma Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: svn-src-head , svn-src-all , src-committers , John Baldwin X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 22:17:58 -0000 On Mon, Jan 26, 2015 at 10:50 PM, Nick Hibma wrote: > > > On 26 Jan 2015, at 22:24, John Baldwin wrote: > > > > > > It might. What happened for me is that I was using nat over wlan0 for > VM's > > on my laptop to reach the outside world, but wlan0 doesn't get an IP > until > > later in the boot after it associates. As a result, wlan0 wasn't > passing any > > IP traffic until this fix (or if I reloaded ipfw after wlan0 was > configured). > With a FreeBSD 11-current 277728 I still have the ipfw_nat problem on unconfigured/unexistant interface. > > I don't think it does. The interface is not available until openvpn is > started.You need to clone the interface during boot by adding > > cloned_interfaces='tun0' > > in your /etc/rc.conf. Initialisation is then done later by openvpn. > > Let me know if that works for you. > > I've tried with cloned_interfaces too: but same problem. Here is the status of ipfw just after a boot (ipfw loaded before tun0 IP setup): []~> ipfw show 00100 0 0 allow ip from any to any via lo0 00200 0 0 allow ip from any to any via lo1 00300 0 0 allow ip from any to any via vtnet6 00400 0 0 allow ip from any to any via wlan0 00500 172 21355 nat 1 ip from any to any in via vtnet4 00600 62 4264 nat 2 ip from any to any in via tun0 00700 0 0 check-state 00800 0 0 allow udp from 0.0.0.0 68 to 255.255.255.255 dst-port 67 out via vtnet4 00900 0 0 allow udp from any 67 to me dst-port 68 in via vtnet4 01000 0 0 allow udp from any 67 to 255.255.255.255 dst-port 68 in via vtnet4 01100 0 0 allow icmp from me to any out via vtnet4 keep-state 01200 11 756 allow udp from me to any dst-port 53 out via vtnet4 keep-state 01300 4 304 allow udp from me to any dst-port 123 out via vtnet4 keep-state 01400 172 21725 allow udp from me to any dst-port 1195 out via vtnet4 keep-state 01500 0 0 nat 1 ip from 10.6.1.0/24,10.6.2.0/24 to any out via vtnet4 01600 0 0 nat 2 udp from me to 2.2.2.2 dst-port 1812,1813 out via tun0 01700 68 4452 allow ip from any to any via tun0 65535 0 0 deny ip from any to any => All rules are present (even the "nat 2" table) and seems ok. => No packet seems to be denied But my OSPF adjacency didn't came up on the tun0 interface: []~> tcpdump -pni tun0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tun0, link-type NULL (BSD loopback), capture size 262144 bytes capability mode sandbox enabled 21:25:09.555746 IP 10.0.3.2 > 224.0.0.5: OSPFv2, Hello, length 44 21:25:10.595286 IP 10.0.3.1 > 224.0.0.5: OSPFv2, Hello, length 48 ^C 2 packets captured 2 packets received by filter 0 packets dropped by kernel => tcpdump shows only some multicast traffic: It's the problem because ifpw is filtering all unicast traffic on tun0 in its current state. For solving this problem I just had to reload ipfw: []~> service ipfw restart net.inet.ip.fw.enable: 1 -> 0 net.inet6.ip6.fw.enable: 1 -> 0 Firewall rules loaded. => This fix the problem, unicast traffic are now allowed: []~> tcpdump -pni tun0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tun0, link-type NULL (BSD loopback), capture size 262144 bytes capability mode sandbox enabled 21:25:34.772225 IP 10.0.3.2 > 10.0.3.1: OSPFv2, Database Description, length 32 21:25:35.784449 IP 10.0.3.1 > 10.0.3.2: OSPFv2, Database Description, length 32 21:25:35.784550 IP 10.0.3.2 > 10.0.3.1: OSPFv2, Database Description, length 52 21:25:35.785904 IP 10.0.3.1 > 10.0.3.2: OSPFv2, Database Description, length 192 21:25:35.786007 IP 10.0.3.2 > 10.0.3.1: OSPFv2, Database Description, length 32