[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: synproxy problems with bridge
On Fri, 13 Jun 2003 09:06:50 +0200
Daniel Hartmeier <[email protected]> wrote:
> The only workaround at this time is to assign IP addresses to the
> interfaces of the bridge. This results in routing table entries on the
> bridge machine, which allows the packets generated by pf to get sent
> out. This is obviously only doable when you have separate networks
> (two non-overlapping netblocks) on each interface of the bridge.
> pf operates on IP (not ethernet) level. It uses a function of the
> existing TCP/IP stack (ip_output) to send out IP packets it generates.
> This function then needs to decide which interface the destination IP
> address is reachable through, and find the MAC address of the
> destination IP address (or a gateway to it). It uses the routing table
> (and arp cache) to do that, which is empty on a pure bridge (one
> without IP addresses assigned to the interfaces).
> For some pf generated packets (like return-* or synproxy), the
> destination is always either the source or destination of the packet
> that was just filtered/received by pf, so we could theoretically try
> to use the ethernet level information in the packet (which pf
> currently ignores, operating purely on IP level). Other packets (like
> route-to) may need a completely new destination, so the MAC address
> may be entirely unknown. If a solution can be found which doesn't
> require duplicating large parts of code (from ip_output into pf), that
> would be welcome. But we don't have that yet.
Thanks for the explanation, that makes sense. And even more thanks for
an extraordinary packet filter. I don't know what I would do without