Hello Daniel, That does seem to be similar to the issue I'm seeing, but sadly there was no solution there for pf and I was unable to get the ipfw psuedo configuration to work with pf. Re-routing to the loopback address as you suggest does not allow the TCP handshake to complete. I tried using "synproxy state", also to no avail.
I don't understand how rerouting the the loopback address would solve this. There are 2 steps here - first the TCP handshake needs to be completed and then the kernel/pf needs to pass the packets to the correct socket. How is this supposed to work in pf? Or is this hidden/implicit in certain rule definitions? Thanks for looking at this. -- Gerald McNulty On Fri, Jan 6, 2012 at 7:42 AM, Daniel Hartmeier <[email protected]>wrote: > On Fri, Jan 06, 2012 at 02:51:07AM +0000, Gerald McNulty wrote: > > > Is this something that requires further pf rules? Or something in the C > > code? > > I think you're describing > > http://lists.freebsd.org/pipermail/freebsd-net/2011-March/028225.html > > With pf, you could try to reroute the replies to the loopback interface: > > pass out on $ext_if reply-to lo0 inet proto tcp user {uid} keep state > > Maybe first start by matching on a specific IP (e.g. 100.100.100.5) instead > of the uid, as a test. > > HTH, > Daniel > _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "[email protected]"
