From owner-freebsd-ipfw@FreeBSD.ORG Sat Jan 7 20:20:11 2012 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A459106564A for ; Sat, 7 Jan 2012 20:20:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 547E28FC12 for ; Sat, 7 Jan 2012 20:20:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q07KKB7E022833 for ; Sat, 7 Jan 2012 20:20:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q07KKB7G022832; Sat, 7 Jan 2012 20:20:11 GMT (envelope-from gnats) Date: Sat, 7 Jan 2012 20:20:11 GMT Message-Id: <201201072020.q07KKB7G022832@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org From: Greg Radzykewycz Cc: Subject: Re: kern/163873: ipfw fwd does not work with 'via interface' in rule body X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Greg Radzykewycz List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2012 20:20:11 -0000 The following reply was made to PR kern/163873; it has been noted by GNATS. From: Greg Radzykewycz To: =?windows-1251?b?yu7t/Oru4iDF4uPl7ejp?= Cc: freebsd-gnats-submit@freebsd.org Subject: Re: kern/163873: ipfw fwd does not work with 'via interface' in rule body Date: Sat, 7 Jan 2012 11:35:27 -0800 Greetings =CA=EE=ED=FC=EA=EE=E2, Thank you for looking into this and your response. If you will note though = and=20 even with traffic originated locally and only a single functioning interfac= e,=20 forwarding fails to occur when the ipfw rule contains "via interface". According to the ipfw man page. fwd | forward ipaddr | tablearg[,port] Change the next-hop on matching packets to ipaddr ... If ipaddr is not a local address, then the port number (if specifed) is=20 ignored, and the packet will be forwarded to the remote address, using the= =20 route as found in the local routing table for that IP. In the testing that was done where there was only one active interface, em0= ,=20 when "via em0" was added to the ipfw rule, forwarding failed. Without "via= =20 em0" in the rule, forwarding worked. That was the only difference. Perhaps it is important to note that in both the production and test=20 evnironments the IP address that was being forwarded to was on a local=20 Ethernet network. In the test environment, the firewall's IP address=20 (192.168.0.34), the default route (192.168.0.1) and the forward IP address= =20 (192.168.0.10) were on the same em0 interface and in the same /24 network. I hope this help. And thanks again! =2D-=20 Warmest Regards Greg Radzykewycz Manager of Information Systems Inland Cellular / Inland Networks On Friday 06 January 2012 13:25:27 you wrote: > =C7=E4=F0=E0=E2=F1=F2=E2=F3=E9=F2=E5, Greg. >=20 > =C2=FB =EF=E8=F1=E0=EB=E8 6 =FF=ED=E2=E0=F0=FF 2012 =E3., 23:07:40: > >>Number: 163873 > >>Category: kern > >>Synopsis: ipfw fwd does not work with 'via interface' in rule body > >>Confidential: no > >>Severity: non-critical > >>Priority: low > >>Responsible: freebsd-bugs > >>State: open > >>Quarter: > >>Keywords: > >>Date-Required: > >>Class: sw-bug > >>Submitter-Id: current-users > >>Arrival-Date: Fri Jan 06 21:10:09 UTC 2012 > >>Closed-Date: > >>Last-Modified: > >>Originator: Greg Radzykewycz > >>Release: 8.2-RELEASE >=20 > >>Organization: > GR> Inland Networks >=20 > >>Environment: > GR> FreeBSD pandora.inlandnet.com 8.2-RELEASE FreeBSD 8.2-RELEASE #0: > GR> Wed Dec 21 09:06:00 PST 2011 > GR> root@pandora.inlandnet.com:/usr/src/sys/i386/compile/PANDORA i386 >=20 > >>Description: > GR> This PR may be related to the following PRs. > GR> kern/129036 > GR> kern/122963 >=20 > GR> In upgrading a firewall from FreeBSD 4.11 to 8.2 there was a > GR> problem with the firewall not forwarding DNS queries to a DNS > GR> proxy server running on another box. The firewall rules were > GR> identical between 4.11 and 8.2. Sample rule follows. >=20 > GR> ${fwcmd} add fwd ${dnsproxy} udp from any to ${atldns1} domain in via > ${iif1} try to add before your rule this one: > ${fwcmd} add log fwd ${dnsproxy} udp from any to ${atldns1} domain >=20 > and see /var/log/security to obtain how kernel see that packet >=20 > Also notice that when you receive 'via rl0' and you try to fwd to > address that is reachable on rl3 the packet will have state 'out xmit rl3' > and not 'via rl0', as you expect, maybe. >=20 > GR> While this worked on 4.11, it did not on 8.2. >=20 > GR> After a Google search turned up nothing pertinent, testing > GR> different variations of the firewall rule was done. The box was > GR> taken out of service and reconfigured for testing. Testing was done > with TCP for simplicity. >=20 > GR> The following worked. > GR> ipfw add 350 fwd 192.168.0.10 tcp from any to 10.10.10.10 53 >=20 > GR> With tcpdump running on 192.168.0.10, packets to 10.10.10.10 TCP > GR> port 53 were seen when the command "telnet 10.10.10.10 53" was run on > the firewall box. >=20 > GR> The following did not work. > GR> ipfw add 350 fwd 192.168.0.10 tcp from any to 10.10.10.10 53 via em0 >=20 > GR> Interface em0 was the only interface connected and configured at > GR> the time and also was the default route (192.168.0.1). Any > GR> external IP traffic would pass through em0 regardless. Doing the > GR> same test with tcpdump running on 192.168.0.10, packets to > GR> 10.10.10.10 TCP port 53 were not seen on 192.168.0.10 when the > GR> command "telnet 10.10.10.10 53" was run on the firewall box. >=20 > GR> The firewall box was reconfigured for production use. The > GR> firewall rules associated with proxying DNS requess were all > GR> changed to remove 'in via ${iif}' and the box was put back in > GR> service. Without the 'in via' in the rules, it functioned as > GR> expected proxying the DNS queries. >=20 > >>How-To-Repeat: > GR> See description. The problem was consistent and repeatable. >=20 > >>Fix: > GR> Unknown. >=20 > >>Release-Note: > >>Audit-Trail: >=20 > >>Unformatted: > GR> _______________________________________________ > GR> freebsd-bugs@freebsd.org mailing list > GR> http://lists.freebsd.org/mailman/listinfo/freebsd-bugs > GR> To unsubscribe, send any mail to > GR> "freebsd-bugs-unsubscribe@freebsd.org"