"ipfw fwd" rules commonly used to implement policy-based routing. Very often they are used to change outgoing interface for packet. For incoming packet, "ipfw fwd" changes next-hop but fails to change outgoing interface name if it changes with new next-hop assignment. Fix: Unknown. With some care, ipfw ruleset may be changed to workaroung the problem but real fix is needed - kernel should correct name of ougoing interface for such cases so ipfw won't make mistakes. How-To-Repeat: Assume a packet from 10.0.0.1 comes in via em0 and according to routing table should be forwarded via em1. When another router 192.168.0.1 is directly connected through em2: ipfw add 1000 fwd 192.168.0.1 ip from 10.0.0.0/8 to any in recv em0 ipfw add 2000 divert 5000 ip from any to any out xmit em1 Our packet is matched by rules 1000, so it's next-hop is changed to 192.168.0.1 and it will really go out em2. But at second ipwf rulest pass it is matched with rules 2000 to. That's really bad - packet is passed to userland application or netgraph mode listening on divert port 5000 but it must not.
Responsible Changed From-To: freebsd-bugs->freebsd-ipfw Over to maintainer(s).
State Changed From-To: open->feedback Can you still reproduce this on a supported release?
> Can you still reproduce this on a supported release? Yes, the same problem can be reproduced with 8.2-STABLE. Eugene Grosbein.
Can't reproduce on both 9.0 and 8.3. Could you test on them please?
27.02.2012 20:11, Sergey Matveychuk ÐÉÛÅÔ: > Can't reproduce on both 9.0 and 8.3. Could you test on them please? I've just testet 8.3-PRERELEASE and problem is still here. In my current setup, the router based on 8.3-PRE has 3 interfaces: - vr0 is LAN - ng0 is primary uplink (default route points to ng0) - vr1 is secondary uplink. The very first lines of ipfw ruleset are: ipfw add 10 fwd G.G.G.G ip from any to 1.1.1.1 in recv vr0 ipfw add 15 allow ip from any to 1.1.1.1 in ipfw add 20 count ip from any to 1.1.1.1 out xmit ng0 Here G.G.G.G is gateway address of secondary uplink, so route to G.G.G.G points to vr1. And I run "ping -c1 1.1.1.1" from LAN while running "tcpdump -np vr1 host 1.1.1.1". tcpdump shows me that rule 10 works and ICMP packet goes out via vr1. But the packes still matchs rule 20 - that's the problem. Eugene Grosbein
State Changed From-To: feedback->open got feedback. back to open
Responsible Changed From-To: freebsd-ipfw->freebsd-net Reclassify. This problem is not related to ipfw: ipfw(4) sets M_IP_NEXTHOP & adds PACKET_TAG_IPFORWARD on ingress and returns. ip_input() sees M_IP_NEXTHOP and passes packet to ip_forward() which performs routing decision and calls ip_output(). Finally, ip_ouput() calls PFIL hook with ifp determined by ip_forward() and checks M_IP_NEXTHOP _after_ that.
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped
Works in all supported branches, since 10.0-RELEASE at least.