Bug 71910

Comment 1 ru 2004-09-20 08:14:47 UTC

Responsible Changed
From-To: freebsd-bugs->andre

Redirect to Andre.

> >Description:
> 
>   'ipfw fwd' don't forward packet for specified destination
> when packet ip_src is the same machine's.
> 
>   I checked this on 5.3-BETA4 and 6-current
> 

I also ran into this problem when upgrading. I have a machine that is
a NAT box and also have a rule to fwd port 80 connections to our web
proxy machine for transparent proxying. Without this patch the fwd
rule didn't work, but it is working fine with the patch applied.

John
-- 
John Hay -- John.Hay@icomtek.csir.co.za / jhay@FreeBSD.org

This patch fixes "ipfw fwd" for me too.
I implement some sort of outbound load-balancing on two dsl lines by 
forwarding some of the packets to another gateway with my ipfw setup.

FreeBSD nulis.lt 5.3-BETA6 FreeBSD 5.3-BETA6 #2: Sat Oct  2 03:48:29 
EEST 2004     bob@nulis.lt:/usr/src/sys/i386/compile/MIDWAY  i386

The problem still exists on FreeBSD-5.3-STABLE system, and the patch
fixes my problem too.

I have a multihomed server which connects to different networks, and I
want to select the interface for outgoing packets based on incoming
connection. Without this patch 'ipfw fwd' won't forward the outgoing
packet correctly.

FreeBSD elvenbow.nc.kyushu-u.ac.jp 5.3-STABLE FreeBSD 5.3-STABLE #1: Mon Dec  6 20:11:17 JST 2004     root@elvenbow.nc.kyushu-u.ac.jp:/usr/obj/usr/src/sys/ELVENBOW  i386

-- 
Yoshiaki Kasahara
kasahara@nc.kyushu-u.ac.jp

I have run into a closely related problem, however the suggested patch does not fix it.

ipfw fwd will not forward packets to the specified destination when the packet ip_dst is the same as the ip address of the host running the firewall. 

The packet counters in ipfw are incremented, but the packet never makes it out the interface. The packets are instead passed to the local host. 

To reproduce:  
ipfw add 1 fwd <remote ip> ip from any to <local ip>

Hello,

 The problem still exists on  FreeBSD 5.3-RELEASE-p5 system, and the patch
 fixes my problem too.

 I have a dual link Internet connection server. Squid proxy configured
 to forward requests for some clients with different source IP
 addresses. This IP address is local.
 Than this request forwarded by "ipfw fwd" to hi speed uplink.
 
 Without patch system don't forward packets correctly.
 

-- 
WBR Dmitry

Hi all,

  thanx for the patch, it fixed the forward so far that my most
important activity did get operational. :-)

  But the forwarding is still not working correct. There are at
least two remaining bugs (that is, the two I stumbled into by 
accident). I am running 5.3-p5, and I verified both do not appear
with RELEASE-4.7. 

First:
  Nick George noticed it already. More completely said:
If the actual destination address of an outgoing packet is some-
where on a locally attached network, and it shall get routed out
thru some other interface by means of "ipfw fwd", then this fwd 
will get silently ignored and treated as an "accept". That is,
the packet will leave ipfw at this rule, and will NOT be routed
according to the address given in "ipfw fwd", but instead to the
interface that was found in the routing table.

This is easy to reproduce even on a productive system: create a 
tunnel or netgraph interface with a pair of RFC1918 addresses, 
forward some unused service to that external adress, and watch 
with "netstat -i" if the counters increase when trying to contact
this service on various addresses within local netmasks.

Second:
  When an "ipfw forward" directs a packet onto a netgraph iface,
where this netgraph iface works as a loopback and the packet should
be received back into the local system, then this packet will
be moved into netgraph, and will be received back from netgraph,
and then it vanishes! It will not be seen by ipfw again as 
received, neither will it be seen again by anybody else.
That is, the sent counter of the respective netgraph iface 
increases, the received counter of the respective netgraph iface
increases, and thats it.
The loopback can be implemented by two netgraph ifaces, or by
one netgraph iface connected to a netgraph echo. If the same 
loopback is implemented with a tun device and 
"cat /dev/tun2 > /dev/tun2", then the problem does NOT appear,
i.e. then it works as expected.
If packets are routed into such a netgraph loopback not per 
"ipfw fwd", but per normal routing table, then the problem also
does NOT appear, i.e. then the obvious endless loop will happen.

This bug is also easy to reproduce, in the following way:
  1. Create the netgraph objects:
    $ ngctl
    > mkpeer . iface tmp ipx
    > mkpeer .:tmp iface inet inet
    > rmhook . tmp
  2. put a suitable adress onto the interface:
    $ ifconfig ng0 192.168.37.1 192.168.37.2
    $ ifconfig ng1 up
    (the second interface is only receiving, it doesnt need an adress)
  3. put some rules into ipfw (here we try it with http):
    $ ipfw add 10 count log tcp from any to any 80
    $ ipfw add 11 skipto 13 log ip from any to any out recv ng1
    $ ipfw add 12 fwd 192.168.37.2 log tcp from any to any 80 out
  4. watch the packets match rule 12 and then not reappear:
    $ telnet www.google.de 80

Why do I need the functionality: I use a stateful firewall with
natd, so I must keepstate the incoming packets. But an adress to
be nat'ed is actually a jail on the local system, so there are
no incoming packets. With this construct I make them incoming.
-- 
PMc

Hello

I just set up a dual homed box and tried it out with FreeBSD 
5.4-RELEASE-p1 with the following options in the kernel:

options   IPFIREWALL
options   IPFIREWALL_VERBOSE
options   IPFIREWALL_VERBOSE_LIMIT=512
options   IPFIREWALL_DEFAULT_TO_ACCEPT
options   IPFIREWALL_FORWARD
options   IPFIREWALL_FORWARD_EXTENDED
options   IPDIVERT

In the first place I left out the IPFIREWALL_FORWARD_EXTENDED 
options and it was not working. But after a look at the source in 
the place where the patch from this report should have gone, I 
put it in and everything was working as expected, so the patching 
is not needed any more.

But be careful with the IPFIREWALL_FORWARD_EXTENDED option, see 
/usr/src/sys/conf/NOTES. In my setup the 
IPFIREWALL_DEFAULT_TO_ACCEPT option probably does the trick, I 
use it anyway.


bye
Fabian

Comment 9 Andre Oppermann 2005-09-10 08:48:22 UTC

State Changed
From-To: open->closed

Solved by enabling IPFIREWALL_FORWARD_EXTENDED kernel option.