Question about wg(4)

[Konrad Schroder <perseant%hhhh.org@localhost>]

I have a question about wg(4).  I have a situation very similar to the 
"road warrior" topology shown in the wg(4) man page:

         wm0 = 192.0.2.123                     bge0 = 198.51.100.45

         Stationary server:                         Roaming client:
         +---------+                                    +---------+
         |    A    |                                    |    B    |
         |---------|                                    |---------|
         |        [wm0]-------------internet--------[bge0]        |
         |    [wg0] port 1234 - - - (tunnel) - - - - - - [wg0]    |
         |   10.0.1.0                  |               10.0.1.1   |
         |         |                   |                |         |
         +--[wm1]--+          +-----------------+       +---------+
              |               | VPN 10.0.1.0/24 |
              |               +-----------------+
         +-----------------+
         | LAN 10.0.0.0/24 |
         +-----------------+

Configuring this as shown in the manual, and assuming the machines on 
10/24 have A as their default route, will give machine B access to 
resources on 10.0.0.0/24 through the use of a simple

    B# route add -net 10.0.0.0/24 10.0.1.0

In my case, however, machine B does not roam, but is also a server with a 
well-known, public IP address.  I would like the machines on 10.0.0.0/24 
to be able to contact its well-known address through the tunnel.  But if I 
set up a route

    A# route add -host 198.51.100.45 10.0.1.1

I can't see how the tunnel will function at all.

I can think of three solutions to this: (A) fiddle DNS for 10.0.0.0/24 so 
that the machines there contact B at 10.0.1.1, and don't know its public 
address; (B) set up NAT on A so that packets originating on 10/24 are 
rewritten to have a source address of 10.0.1.0; or (C) configure B with a 
second IP address, and bind wg0 to that second address.

(A) sounds risky to me, since if B's public IP address ever "leaked" the 
traffic would either mysteriously be blocked or, worse, silently pass 
unencrypted.  I'd need to add packet filter rules on A to prevent the 
latter.  (B) will not work in my case because I will need to be able to 
identify the peer address from host B, but the peer address would be 
obscured by the NAT.  (C) does not work at present because it is not 
possible to bind wg(4) to a specific address, only a specific port.

How do other people deal with this issue?  I wrote up a patch to allow 
(C), which works but is not yet suitable for commit.  If that is a good 
way to move forward, I'll follow up with some questions on tech-kern.  Or 
am I just missing something obvious?

Thanks,
						Konrad Schroder
						perseant%hhhh.org@localhost