Re: [Openvpn-users] Answering on the same interface where the request came from

[Doncho N. G. <mr...@gl...>]

On 2005 02 22 (Tuesday) 01:39, Neil Brown wrote:
> On Monday February 21, ji...@yo... wrote:
> > 
> > Someone wrote a patch to try to solve this, see the openvpn-devel 
> > archives.
> 
> That would have been me.  However on reflection I am no longer as
> enthusiastic for it as I was.
> 
> I agree that by binding to a specific interface one is able to achieve
> effective (though not precisely) the same result, and it would
> certainly be sufficient to solve my particular problem(*).
> 
> There is a usability issue with the current situation though.  It
> seems to work with 2 interfaces, but it doesn't really work properly.
> 
> There are two ways to fix that inconsistency.  One it to make it work
> "properly", assuming that "properly" actually had a well defined
> meaning and was possible to implement portably - which is apparently
> in doubt.
> The other is to make it not appear to work.
> 
> I don't think it is unreasonable for OpenVPN to only listen on one IP
> address (for UDP at least).  If you want to listen on two addresses,
> then run two instances (or possibly explicitly bind to two addresses
> if that were possible).
> 
> If this were the course that were chosen, then I think that OpenVPN
> should refuse to bind to a wildcard UDP address, simply because that
> functionality isn't completely supported.
> If you don't specify an address in the config file, then it should
> bind to the first (non-localhost) interface (assuming that it is
> possible to find such a thing portably).

    It is still better to have OpenVPN listening to *:port because you
can have one public IP and many internal interfaces. Let's say we have
firewall connected to our LAN, Internet and some our partners (Lan,
Leased Lines). In this case a machine connected to all these will route
the packet based on it's destination address correctly, right?

> That way, if people were to try to use OpenVPN in a non-supported way
> (UDP on multiple interfaces) then it would break quickly (always
> better than breaking slowly) and hopefully lead them to the right part
> of the documentation.

    It is good to be documented and better to be resolved somehow :)
Maybe a hint to the 'Can not send' error message will be a good start?

-- 
Regards,
  Doncho N. Gunchev    Registered Linux User #291323 at counter.li.org
  GPG-Key-ID: 1024D/DA454F79                        http://pgp.mit.edu
  Key fingerprint = 684F 688B C508 C609 0371  5E0F A089 CB15 DA45 4F79