'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 How-To-Repeat: enable kernel option IPFIREWALL and IPFIREWALL_FORWARD ipfw add fwd remote ip from myaddr to any
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
State Changed From-To: open->closed Solved by enabling IPFIREWALL_FORWARD_EXTENDED kernel option.