May I draw attention again on this problem :) PF cannot route the packet back to the socket when using the "divert-reply" option, if a bridge(4) runs over the interface of arrival. Can anything be done for this? Otherwise, it would be good to document this in pf.conf(5), and the inapplicability of the SO_BINDANY option in setsockopt(2).
> Hello folks, > > On a vanilla OpenBSD4.4/i386, I am using the attached spoof.c program > to connect to an address pretending to be a source IP that is not > actually configured on the OpenBSD box. > I use the SO_BINDANY socket option for spoofing, and PF is configured > accordingly (see attached pf.conf). > > When I run eg > > spoof 1.2.3.4 192.168.2.3 > > in a "normal" network setup, spoof actually terminates with a > "Connection > refused" as expected. However, if I switch the box to the bridged > setup I need, > spoof hangs until a timeout is reached. The bridged setup is as follows: > - a pair of interfaces $int_if and $ext_if, members of a bridge0 > - $ext_if is configured with an address of its own to access the inet > - to $int_if there is connected a client, with an address of its own, > that > passes through the bridge to connect to the internet > - spoof generates a SYN packet which is written to both $ext_if and > $int_if, > and the response arrives from the client only on $int_if > > A tcpdump on pflog0 run selectively on the divert-reply rule indicates > that the both request AND response packets are actually picked by that > rule, but the latter is apparently not actually passed to the socket. > At the same time, a tcpdump over $ext_if indicates that the response > from > the client is copied there. > My intuition is that the packet proceeds through the kernel after the > divert-reply > and there it is captured by the bridge(4) driver, thus not making it > to the socket. > In this case, none of the routing rules seems applicable to prevent > the packet > from proceeding through that flow. Is there another possibility, or > divert-reply > is inapplicable when combined with bridge(4)? > > Any other insight is welcome. > thanks > > [demime 1.01d removed an attachment of type application/octet-stream which > had a name of spoof.c] > > [demime 1.01d removed an attachment of type application/octet-stream which > had a name of pf.conf]
