Thanks for the great write-up. On 2011/05/07 16:54, Reyk Floeter wrote: > It is not directly related to the way of > accepting connections on a) and it doesn't really matter if it is via > rdr-to, divert-to or a direct listener on a public IP address.
Ah, this makes sense, because these should only affect the destination address (which, since I have a preset destination rather than doing a nat or getsockname lookup, makes no difference). > From the manpage setsockopt(2): > > SO_BINDANY allows the socket to be bound to addresses which are not local > to the machine, so it can be used to make a transparent proxy. Note that > this option is limited to the super-user. In order to receive packets > for these addresses, SO_BINDANY needs to be combined with matching > outgoing pf(4) divert rules. For example, with the following rule the > socket receives packets for 192.168.0.10 even if it is not a local > address: > > pass out inet from 192.168.0.10 divert-reply Something unusual is happening then, because currently I have no such rule and it's working! > Ok, now back to relayd. As I mentioned before it does not really > matter how the traffic got into relayd. The are different possible > examples to use transparent mode: And something you mentioned to me before, but it's a really feature and worth pointing out in this thread - this can be combined with SSL offload, so the backend HTTP servers still see the original source address. > OK... now the big question: why do we have to specify the "interface > ix1" with the transparent keyword? Answer: the grammar requires it, > but it is currently not used in the code! Ha! This explains why I couldn't track down what it did ;-) > btw.: I'm currently cleaning up the relayd code before I move forward > to implement and fix some outstanding things in relayd. Please have a > look at the large diff that I sent to tech@ yesterday which needs > testers. No new features, just to make sure if this diff doesn't > break any existing setups! Will do.
