Re: Transparent IPv6 proxying on OpenBSD

On 8/03/2012 11:03 p.m., Marios Makassikis wrote:
> Hello,
>
>> Your expectation is correct.
>> For outgoing connections comm_openex() should always receive a
>> destination IP address and port in the remote field.
> Well this is odd actually, because I got it working this morning and
> comm_openex() still has remote=[::]
>
> A few details need to be cleared out first. My setup looks like this:
>
> +---| Internet |---+
> |
> |
> +-----+
> | fw1 |
> +-----+
> |
> |
> +-----+
> | br1 |
> +-----+
> |
> |
> +---Shared LAN---+
>
> Squid is running on br1, which, as the name suggests is a bridge.
> From the wiki page, it seemed bridges can be sources of problems with
> TPROXY, and the solution is to block IPv6 traffic on the bridging
> device.
>
> Since there is no equivalent to ebtables on OpenBSD, and I couldn't get
> PF to do it, I assigned IPv6 addresses on the bridge's interfaces.
> After setting up the corresponding routes, it worked!

This kind of matche sthe Linux requirements, also needing routing setup
to handle the diverted packets.

>
> The client machine behind the bridge can browse the IPv6 internet and I
> see the corresponding entries in access.log
> It also gets blocked when the destination URL matches an ACL in
> squid.conf (squidGuard doesn't support IPv6 AFAIK).
>
> Some mystery still remains though:
> - the remote address reported by comm_openex()

> - the fact that I had to add this rule before the rules handling the
> redirect part:
>
> pass quick inet6 proto udp from<lan_networks> to any port domain
>
> I should add that without the redirect rules, both the bridge and the
> machines behind it can do DNS lookups.

Um, without this which are broken for DNS? just the bridge itself?

>
> - the fact that I had to make br1 visible on the IPv6 network. I say
> that this is odd, as a test with relayd(8) (a relay daemon provided
> in the OpenBSD base system) showed me that transparent IPv6
> proxying works fine on a bridge, without any additional rules
> for DNS queries.

I think this is expected.
The non-diverted packets get bridged normally. But the diverted packets
can't be bridged in the strictest definition of the word. They need to
be passed to local machine socket and that means stepping up the stack
layers through routing decisions. The machine also needs IPs assigned to
receive ICMP / ICMPv6 control messages.

Probably there are also kernel settings somewhere that need to be turned
on (network modules loaded?), and assigning IPs/routes enable them in
the background.

Amos
Received on Thu Mar 08 2012 - 10:38:38 MST