From owner-freebsd-questions Tue Jun 18 8:11:46 2002 Delivered-To: freebsd-questions@freebsd.org Received: from morphy.iki.fi (baana-pppoes-213-139-166-84.suomi.net [213.139.166.84]) by hub.freebsd.org (Postfix) with SMTP id 19A9E37B411 for ; Tue, 18 Jun 2002 08:11:07 -0700 (PDT) Received: (qmail 16646 invoked by uid 1000); 18 Jun 2002 15:11:00 -0000 Date: Tue, 18 Jun 2002 18:11:00 +0300 From: "Mikko S. Hyvarinen" To: freebsd-questions@freebsd.org Subject: Re: ipfw + gif Message-ID: <20020618181100.A16513@morphy.iki.fi> References: <20020617202233.X3574-100000@ah.litech.net> <20020618114913.Q10256-100000@ah.litech.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020618114913.Q10256-100000@ah.litech.net>; from mike@LITech.lviv.ua on Tue, Jun 18, 2002 at 11:52:12AM +0300 Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello Mike, As far as I have understood the issue, this is an artifact of the KAME IPSEC/IPv6 snapshot integrated to FreeBSD on 2001/07/03. In that snapshot integration the following change was made to sys/netinet/ip_input.c (1.130.2.22 -> 1.130.2.23): @@ -385,15 +395,10 @@ m_adj(m, ip->ip_len - m->m_pkthdr.len); } - /* - * Don't accept packets with a loopback destination address - * unless they arrived via the loopback interface. - */ - if ((ntohl(ip->ip_dst.s_addr) & IN_CLASSA_NET) == - (IN_LOOPBACKNET << IN_CLASSA_NSHIFT) && - (m->m_pkthdr.rcvif->if_flags & IFF_LOOPBACK) == 0) { - goto bad; - } +#ifdef IPSEC + if (ipsec_gethist(m, NULL)) + goto pass; +#endif /* * IpHack's section. Label 'pass:' is right after the ipfw filtering hooks. What this change does, in effect, is that all IPSEC packets that have successfully passed the decapsulation will skip right past the ipfw code. This issue was described to me in terms of symptoms a few days ago by a friend of mine, which prompted me to look into the issue. I haven't yet written a PR on this, since I haven't had the time and possibility to test how the system behaves without this particular block of code. Perhaps someone more knowledgeable on the IPSEC implementation internals could confirm this or point out the error(s) in my analysis? Regards, MSH On Tue, Jun 18, 2002 at 11:52:12AM +0300, Mike Futerko wrote: > Hi, > > Note that it is only when I'm using IPsec between > 194.xxx.xxx.210 and 213.xxx.xxx.50 > > Could someone give me suggestions how to fix this? > > Regards, > Mike. > > > > Hello list, > > > > I have a problem with firewalling packets on gif interfaces. > > I'm using gif for building tunnels, ipfw doesn't see incoming packets that came > > on gif interface. > > > > Is it bug or feature? :) > > > > My configuration: > > > > > ifconfig gif2 > > gif2: flags=8051 mtu 1280 > > tunnel inet 194.xxx.xxx.210 --> 213.xxx.xxx.50 > > inet 10.1.10.4 --> 10.1.11.4 netmask 0xffffffff > > > > > ipfw l 5 6 > > 00005 allow log ip from any to 10.1.11.4 > > 00006 allow log ip from 10.1.11.4 to any > > > > When I ping remote side: > > > ping 10.1.11.4 > > PING 10.1.11.4 (10.1.11.4): 56 data bytes > > 64 bytes from 10.1.11.4: icmp_seq=0 ttl=64 time=53.578 ms > > > > I can see only outgoing packets in my log and don't see incoming: > > > tail -f /var/log/security > > > > Jun 17 20:29:17 brama /kernel: ipfw: 5 Accept ICMP:8.0 10.1.10.4 10.1.11.4 out > > via gif2 > > Jun 17 20:29:21 brama last message repeated 4 times > > > > The same behavior with other gif interfaces. > > > > Regards, > > Mike > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-questions" in the body of the message -- All opinions expressed above are mine alone and do not express the views of my employer or any other organizations that I am affiliated with. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message