Bug 71230

I have a firewall system with two interfaces to the internet via two ISPs. As a kindaof hack I used the ipfw fwd rules to force packets out the interface that matched their source address. In effect over-riding the default route.

If interface A: has an address of 1.2.3.4 and a forwarding router of 1.2.3.1 and interface B has an address of 9.8.7.6 with a forwarding router of 9.8.7.1, and interface A has the default route,  I created ipfw rules along the lines of:

fwd 9.8.7.1 ip from 9.8.7.6 to any via B


In effect, intercepting a packet going out the default route and fwding it via the non-default route.

Sorry about the vagueness, the actually application is aiming natd at the non-default route.

In any event, this crude strategy worked just fine with 5.2, but on upgrading to 5.3, all packets that hit the fwd rule are returning EACCES to the sending process.

How-To-Repeat: On a box with two interfaces, do the following:

a) Configure interface A: to 10.0.0.2/24
b) Configure interface B to 10.1.0.2/24
c) Set the default route to be 10.0.0.1, ie, interface A
d) ipfw fwd 10.1.0.1 ip from 10.1.0.0/24 to any via A

e) Write or run a program that binds to an interface B address and send a packet to some random external address, say, 192.168.0.1

The point about e) is that you are binding to the non-default-route address.
The point about d) is that you are catching default-route traffic and forwarding it down another pipe.

This represents my scenario, but quite possibly any ipfw fwd rule will produce the same result. Namely that the application that does a sendto() that hits a fwd rule gets EACCES.