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]
