Re: Endpoint address dns resolution - option to prefer IPv6 or IPv4

2020-03-15 Thread Roman Mamedov
On Sat, 14 Mar 2020 15:51:51 +0100
Torsten Krah  wrote:

> resend to the list:
> 
> Hm, sorry I don't get the message. Imho its down to the user. I can
> choose to use ping or ping6 or tell e.g. java via a system property to
> prefer IPv4 if dual stack is available.
> 
> In wireguard I can force ipv6 only by writing an ipv6 address in the
> endpoint, but via dns ... how to choose which one I prefer?

If it is so important to you to force one or the other, then make separate DNS
records for IPv4 and IPv6, server4.example.com, server6.example.com.

-- 
With respect,
Roman


Re: Endpoint address dns resolution - option to prefer IPv6 or IPv4

2020-03-15 Thread Torsten Krah
I don't use NetworkManager - just the wireguard command line tool -
searching a way to configure the preference on v4/v6.


Re: WireGuard connecting hosts WAN->LAN

2020-03-15 Thread Kent Friis
> Scenario:
> A = internet (WAN) host (WireGuard IP 10.1.1.3)
> B = OpenWRT router (WireGuard IP 10.1.1.1)
> C = LAN host (WireGuard IP 10.1.1.2)

What you have been told is correct for the case of A connecting to C.
there is no way for A to reach the Wireguard port on C without B
forwarding that port.

However, if you can turn it around and have C connect to A, assuming
the wireguard port on A is accessible from the internet, C will be able
to connect to A. Once the connection is established, traffic will flow
both ways.


Re: Endpoint address dns resolution - option to prefer IPv6 or IPv4

2020-03-15 Thread Torsten Krah
resend to the list:

Hm, sorry I don't get the message. Imho its down to the user. I can
choose to use ping or ping6 or tell e.g. java via a system property to
prefer IPv4 if dual stack is available.

In wireguard I can force ipv6 only by writing an ipv6 address in the
endpoint, but via dns ... how to choose which one I prefer?

kind regards


Re: Endpoint address dns resolution - option to prefer IPv6 or IPv4

2020-03-15 Thread Stefan Tatschner
On Fri, 2020-03-13 at 15:52 +0100, Torsten Krah wrote:
> I would like to configure the client, so that I can tell him, to
> either prefer IPv6 or IPv4 for the vpn connection.

If you use the Wireguard Support in NetworkMananger, it does update the
Endpoint dynamically. I am not sure if you can configure a preference
on v4/v6, but at least it updates the endpoint automatically depending
on the current network capabilities. IIRC it uses the system wide
settings in /etc/gai.conf.



Logging

2020-03-15 Thread J.R. Oldroyd
Hi all,

New here.  Apologies if I am re-hashing something discussed before.
I did read back a few months of this list and didn't see any relevant
discussion.

Unlike many here who are providing anonymous VPN services and who
don't want logging at all, I am helping set up Wireguard in a corporate
VPN environment.  The logging requirements here are very different.

Specifically, there is a need for permanent logs.  And, the logs should
ideally include:

- when a client connects
- when a client disconnects
- ideally also how much data was transferred in and out
  during a session

So this is precisely the opposite logging requirement from those
who are managing anonymous VPNs.  That's understood, and my proposed
changes maintain current default no-logging behavior for those that
need no logging.

I have made replacements [1] for device/logger.go that allow syslog
to be used for logging if available.

There are two files, both are needed.  There are OS-dependent
compilation directives so that the syslog version is not used on
Windows or Plan9, which do not have syslog.

In both, the behavior is exactly the same as now by default.  If no
other config is used, logging is still at info level to stdout as is
current practice.  I.e., you can drop these in and nothing will change
for current users, even on systems that support syslog.

To use the new syslog logging, environment variables must be set.
Logging level and logging destination are controlled by the existing
variable LOG_LEVEL and the new WG_LOG_DEST and WG_LOG_FACILITY:

LOG_LEVEL   "debug", "info", "error", "silent"
(default is still "info")

WG_LOG_DEST "stdout", "syslog"
(default is "stdout")

WG_LOG_FACILITY
any syslog facility, e.g., "daemon", "local0",
"local1", etc (also "log_", prefix OK and
either lower- or upper-case)
(default is "daemon")

Note that when using syslog, your syslog.conf needs to be configured
to send messages from your chosen facility.level to somewhere useful.

Also, it's worth saying that wireguard-go's logging includes some
UTF-8 characters.  Certain OSs' syslogd don't handle 8-bit data
very well.  E.g., FreeBSD.  A patch for FreeBSD's syslogd is at [2].

Since this is backwards compatible, it would be great to see this
logger.go and logger_syslog.go replace the current logger.go.

I have also been playing with some patches to add the session start and
end log messages.  I realize that this is a stateless protocol and that
the idea of a session isn't really there.  While my current placement of
these session log messages in receive.go and in timers.go is close, it
isn't perfect.  Right now I am logging "session start" in the initial
handshake code and "session end" in the handshake timeout code.  Neither
are perfect but, as I said, close.  I need to look more at the peer
state information that is currently maintained in order to see if
there's a better place to put these log messages.  I realize also that
these session log messages must not be logged for those who don't want
any logging.  These session log patches are NOT part of the current
proposed logger.go changes.  If anyone wants to see these, I'll send
them along separately.

-jr

[1] optional syslog logging for wireguard-go
http://opal.com/jr/wireguard/logger.go
http://opal.com/jr/wireguard/logger_syslog.go
(both files are needed)

[2] Patch for FreeBSD's syslogd to support UTF-8 chars in messages
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244226