Re: [Openvpn-devel] [PATCH v3] Parse static challenge response in auth-pam plugin

2018-07-29 Thread Selva Nair
Hi, On Sun, Jul 29, 2018 at 3:34 PM, Gert Doering wrote: > Hi, > > On Tue, Jul 24, 2018 at 10:34:53PM -0400, selva.n...@gmail.com wrote: >> From: Selva Nair >> >> If static challenge is in use, the password passed to the plugin by openvpn >> is of the form "SCRV1:base64-pass:base64-response". Pa

Re: [Openvpn-devel] [PATCH v3] Parse static challenge response in auth-pam plugin

2018-07-29 Thread Gert Doering
Hi, On Tue, Jul 24, 2018 at 10:34:53PM -0400, selva.n...@gmail.com wrote: > From: Selva Nair > > If static challenge is in use, the password passed to the plugin by openvpn > is of the form "SCRV1:base64-pass:base64-response". Parse this string to > separate it into password and response and use

Re: [Openvpn-devel] Set interface metric instead letting it on auto (OS choice) when we have redirect-gateway present to enforce the desired effect for IPv6

2018-07-29 Thread Selva Nair
Hi > > Thanks for the hint Selva. Indeed it looks like something DNS related. > The primary wired network interface has 1 IPv4-listening DNS server > (192.168.1.1, which uses 2 upstream IPv4-listening DNS server from the > ISP). The tun device has 2 IPv4 listening DNS servers (google) and 2 > IPv

Re: [Openvpn-devel] Set interface metric instead letting it on auto (OS choice) when we have redirect-gateway present to enforce the desired effect for IPv6

2018-07-29 Thread s7r
Selva Nair wrote: >> >> Hope this information is sufficient. > > Not really. Sounds like DNS resolution is changing with metric of the > interface which very much points to a WIndows only behaviour. > > And, in that case whether a DNS server is set on the tun interface and > which DNS server gets

Re: [Openvpn-devel] Set interface metric instead letting it on auto (OS choice) when we have redirect-gateway present to enforce the desired effect for IPv6

2018-07-29 Thread Gert Doering
Hi, On Sun, Jul 29, 2018 at 04:46:14AM +0300, s7r wrote: > Sorry - I have missed this information because I thought it's irrelevant > and it should apply to _any_ operating system, if it is to be applied at > all. The OS where I experienced the behavior is Windows 10 Enterprise > (64 bit) all up t