kern/163873: ipfw fwd does not work with 'via interface' in rule body

Sat Jan 7 20:20:11 UTC 2012

The following reply was made to PR kern/163873; it has been noted by GNATS.

From: Greg Radzykewycz <sysmgr at inlandnet.com>
To: =?windows-1251?b?yu7t/Oru4iDF4uPl7ejp?= <kes-kes at yandex.ru>
Cc: freebsd-gnats-submit at 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 at 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 at freebsd.org mailing list
 > GR> http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
 > GR> To unsubscribe, send any mail to
 > GR> "freebsd-bugs-unsubscribe at freebsd.org"