Date: Sat, 7 Jan 2012 20:20:11 GMT From: Greg Radzykewycz <sysmgr@inlandnet.com> To: freebsd-ipfw@FreeBSD.org Subject: Re: kern/163873: ipfw fwd does not work with 'via interface' in rule body Message-ID: <201201072020.q07KKB7G022832@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/163873; it has been noted by GNATS.
From: Greg Radzykewycz <sysmgr@inlandnet.com>
To: =?windows-1251?b?yu7t/Oru4iDF4uPl7ejp?= <kes-kes@yandex.ru>
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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201201072020.q07KKB7G022832>