Daniel, thanks for the unexpectedly quick response! This combination of rules does work, just like you said.
rdr on aue0 proto tcp from any to any port 9999 -> 192.168.2.250 port 22 pass out on dc0 route-to lo0 proto tcp from any to 192.168.2.250 port 22 Thanks a ton! You rock! > On Tue, Feb 04, 2003 at 11:35:29PM -0600, Mike McClure wrote: > >> So, one would expect a workstation on network A to be able to connect to port 9999 >> on a given address and get the SSH daemon on the OBSD system, correct? > > Not on a bridge, if the destination mac address of the incoming frame is > doesn't match one of the bridge's own interfaces. > > 192.168.2.10 sends the ethernet frame to the mac address of the default > gateway (add -e to the tcpdump options to see the mac addresses), and > the bridge doesn't care whether the destination IP address has changed > to one of its own IP addresses during translation. It operates only on > mac addresses. > > So, the destination mac address is not its own, and the frame gets sent > out through the interface where the destination is reachable (dc0). The > frame never gets forwarded to the firewall's own TCP/IP stack at all. > > I doubt this exact same setup has worked with 3.1, as there were no > bridge changes relevant to this. Possibly the gateway used to forward > the packets back to 192.168.2.250 before, and now doesn't. But the > bridge code never looked at the destination IP address after translation > to direct the packet to the stack instead of forwarding the frame. > > You can try using 'fastroute' or 'route-to' to manually route the > packets to the stack from pf (so the bridge will not get the packet back > from pf, and pf does the forwarding). > > Daniel > > -- Mike McClure, CCIE # 5125, CISSP # 30232 PNE Services, Inc. - http://www.pneservices.com [EMAIL PROTECTED] mobile: 913-636-5590
