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
