[Zebedee-talk] Bug in 2.4.1 -- target host resolution happens at client, not at server

[William H. <wha...@po...>]

Version 2.4.1 (possibly also 2.5.2 ?) attempts to resolve the hostname =
of
the destination server locally -- and errors out if it cannot do so -- =
even
when a separate "serverhost" entry has been provided.  This makes it
extremely difficult to initiate a Zebedee connection in the following
situation:

--> [Zebedee client on PC_1] --> [firewall port-forwarding to PC_2] -->
[Zebedee server on PC_2] --> [port on PC_3]

PC_1 can only resolve the hostname (or be supplied with the IP address) =
of
the firewall.  The firewall is configured to forward port 11965 to the =
same
port on PC_2.  PC_3 has a dynamically assigned IP address, which PC_2, =
on
the same LAN, has no trouble resolving from its hostname.

PC_1, not on the same LAN as PC_2 and PC_3, cannot resolve PC_3's =
hostname,
so the tunnel fails.  Assuming we only care about PC_3, this is trivial =
to
solve by having PC_3 be PC_2's default target, and using "*" in place of
"PC_3" in the tunnel spec.  However, if "PC_3" may be any of dozens of
target PCs on PC_2's LAN, with targets being added or removed on a daily
basis and tracked in the local DNS server, that is not really an option. =
 To
fix this bug requires the following modification of the Zebedee client's =
and
Zebedee server's behavior:

Client: if a serverhost is supplied, resolve that at the client, but =
pass
the target hostname to the server unresolved.
Server: be prepared to perform DNS resolution of requested target =
hostnames
supplied by the client.

Since the server apparently already does this in the process of checking
whether a requested target is among the listed acceptable targets, that =
part
should be fairly simple.  Similarly, since the behavior needed at the =
client
is to refrain from doing something that it currently does, that should =
also
be fairly simple.

However, I have not recompiled Zebedee for Win32 and do not presently =
have
time to work that out in addition to identifying the necessary =
modification
in the 2.4.1 source to fix the bug.  If I identify and post the source
modifications, would someone who has compiled Zebedee 2.4.1 for Win32 be
willing to make the modifications, recompile the executable, and test to
confirm that the fix works correctly?

- w.h.

Note: until the bug is fixed, here are some more or less complicated
workarouunds:

1) Tunnel DNS to the DNS server on the PC_2/PC_3 LAN separately and =
adding
127.0.0.1 to PC_1's DNS server search list; it might be necessary to set =
up
a caching DNS server actually on PC_2, in this scenario, although we can
hope not.  Tested with DNS server on PC_2; not tested successfully with
forwarding DNS traffic to PC_2's local DNS server, but did not invest =
enough
time to find out why it didn't work and whether it could be made to.

2) Configure port-forwarding on the firewall to forward a different port =
on
the firewall to port 11965 on each PC on the LAN.  This does not scale =
well,
and with some low-end firewalls is not even possible.

3) Set up Zebedee on PC_2 to run simultaneously on different server =
ports,
with a different default target configured for each copy; this permits =
PC_1
to select the destination host by using a localport:*:remoteport tunnel
spec, and a different serverport entry depending on the actual =
destination
PC desired.  This solution does not scale well, but has been tested and =
does
work.

4) Set up multiple permanent (service-mode) Zebedee client connections =
from
PC_2 to each desired target PC, forwarding a different exposed port on =
PC_2
to port 11965 on the target PC; this allows the use of a nested pair of
tunnels to communicate "directly" from PC_1 to PC_3.  This solution does =
not
scale well, but has been tested and does work.