Menu
▾
▴
openvpn-users
|
From: Vincent B. <be...@lu...> - 2005-02-21 15:49:39
|
Hello ! I have a box with two Internet connections and I have an OpenVPN listening to all interfaces. I have a default route to one of the connections and I use iproute2 to ensure that what is sent with the address of the second connection is really sent to the second connection : 200: from 82.67.232.xxx lookup ADSL And in table ADSL : default via 82.67.232.254 dev eth2 Therefore, when I connect through ssh to 82.67.232.xxx, all is working fine, even if the default route uses another IP. ICMP and UDP are also working fine (I don't know the magic behind since they are connection-less). However, with OpenVPN, if I connect to 82.67.232.xxx, OpenVPN always answers with the other IP and therefore, the answer is sent via the default interface. I use OpenVPN 2.0rc12 (from Debian). Any idea ? -- I WILL NOT AIM FOR THE HEAD I WILL NOT AIM FOR THE HEAD I WILL NOT AIM FOR THE HEAD -+- Bart Simpson on chalkboard in episode 8F13 |
|
From: Christian <chr...@ce...> - 2005-02-21 16:10:51
|
On Monday 21 February 2005 16:49, Vincent Bernat wrote: > Hello ! > > I have a box with two Internet connections and I have an OpenVPN > listening to all interfaces. I have a default route to one of the > connections and I use iproute2 to ensure that what is sent with the > address of the second connection is really sent to the second > connection : > > 200: from 82.67.232.xxx lookup ADSL > > And in table ADSL : > > default via 82.67.232.254 dev eth2 > > Therefore, when I connect through ssh to 82.67.232.xxx, all is working > fine, even if the default route uses another IP. ICMP and UDP are also > working fine (I don't know the magic behind since they are > connection-less). However, with OpenVPN, if I connect to > 82.67.232.xxx, OpenVPN always answers with the other IP and therefore, > the answer is sent via the default interface. > > I use OpenVPN 2.0rc12 (from Debian). Any idea ? Assuming that iproute2 setup is working correctly, try running two openvpn servers and bind each server (local parameter in openvpn server configuration) to the ip address for each internet connection. Actually, when using TCP as openvpn carrier this should not necessary, but when using UDP as carrier I have found that I had to use two openvpn servers (one for each line) bound to the apropriate ip address to get traffic to return out the corresponding line. Christian |
|
From: Vincent B. <be...@lu...> - 2005-02-21 16:44:39
|
OoO Lors de la soir=E9e naissante du lundi 21 f=E9vrier 2005, vers 17:10=
,
Christian R=F8snes <chr...@ce...> disait:
>> Therefore, when I connect through ssh to 82.67.232.xxx, all is working
>> fine, even if the default route uses another IP. ICMP and UDP are also
>> working fine (I don't know the magic behind since they are
>> connection-less). However, with OpenVPN, if I connect to
>> 82.67.232.xxx, OpenVPN always answers with the other IP and therefore,
>> the answer is sent via the default interface.
>>=20
>> I use OpenVPN 2.0rc12 (from Debian). Any idea ?
> Assuming that iproute2 setup is working correctly, try running=20
> two openvpn servers and bind each server (local parameter in
> openvpn server configuration) to the ip address for each
> internet connection.
> Actually, when using TCP as openvpn carrier this should not necessary,=20
> but when using UDP as carrier I have found that I had to use two openvp=
n=20
> servers (one for each line) bound to the apropriate ip address to
> get traffic to return out the corresponding line.
Thanks for your answer. May those two OpenVPN instances share the same
pool config file and the same range. I mean, may I have the same
server directive and the same ifconfig-pool-persist directive ?
--=20
Modularise. Use subroutines.
- The Elements of Programming Style (Kernighan & Plaugher)
|
|
From: Christian <chr...@ce...> - 2005-02-21 17:43:28
|
On Monday 21 February 2005 17:44, Vincent Bernat wrote: > OoO Lors de la soir=E9e naissante du lundi 21 f=E9vrier 2005, vers 17:10, > > Christian R=F8snes <chr...@ce...> disait: > >> Therefore, when I connect through ssh to 82.67.232.xxx, all is working > >> fine, even if the default route uses another IP. ICMP and UDP are also > >> working fine (I don't know the magic behind since they are > >> connection-less). However, with OpenVPN, if I connect to > >> 82.67.232.xxx, OpenVPN always answers with the other IP and therefore, > >> the answer is sent via the default interface. > >> > >> I use OpenVPN 2.0rc12 (from Debian). Any idea ? > > > > Assuming that iproute2 setup is working correctly, try running > > two openvpn servers and bind each server (local parameter in > > openvpn server configuration) to the ip address for each > > internet connection. > > > > Actually, when using TCP as openvpn carrier this should not necessary, > > but when using UDP as carrier I have found that I had to use two openvpn > > servers (one for each line) bound to the apropriate ip address to > > get traffic to return out the corresponding line. > > Thanks for your answer. May those two OpenVPN instances share the same > pool config file and the same range. I mean, may I have the same > server directive and the same ifconfig-pool-persist directive ? I would think that it would be advisable to use different pools for each openvpn server, so that there's not any chance of=20 concurrently handing out the same ip address on both servers=20 (to two different clients connections). I use e.g pools: 10.91.0.0/24 for server1 (tun1), and=20 10.92.0.0/24 for server2 (tun2) On the openvpn server I also source nat the 10.91.0.0/24 and 10.92.0.0/24=20 addresses to local lan addresses (openvpn server lan), eg 192.168.1.11 and= =20 192.168.1.12, respectively.=20 That way the surrounding firewalls, routers, other servers, and what have you on the openvpn server side, do not need to=20 know about routing for the 10.91.0.0 and 10.92.0.0 addresses=20 because they only see the natted addreses 192.168.1.11 and 192.168.1.12. Christian |
|
From: Charles D. <cd...@sp...> - 2005-02-21 17:55:59
|
On Mon, 21 Feb 2005 17:44:33 +0100, Vincent Bernat wrote: > Thanks for your answer. May those two OpenVPN instances share the same > pool config file and the same range. I mean, may I have the same > server directive and the same ifconfig-pool-persist directive ? No. There's enough unroutable IP space, though, for you to just give them different ranges. For instance: 172.16.0.0 255.255.0.0 172.16.16.0 255.255.0.0 ... 172.16.224.0 255.255.0.0 172.16.240.0 255.255.0.0 |
|
From: Doncho N. G. <mr...@gl...> - 2005-02-21 21:52:54
|
On 2005-02-21 (Monday) 17:49, Vincent Bernat wrote:
> Hello !
>
> I have a box with two Internet connections and I have an OpenVPN
> listening to all interfaces. I have a default route to one of the
> connections and I use iproute2 to ensure that what is sent with the
> address of the second connection is really sent to the second
> connection :
>
> 200: from 82.67.232.xxx lookup ADSL
>
> And in table ADSL :
>
> default via 82.67.232.254 dev eth2
>
> Therefore, when I connect through ssh to 82.67.232.xxx, all is working
> fine, even if the default route uses another IP. ICMP and UDP are also
> working fine (I don't know the magic behind since they are
> connection-less). However, with OpenVPN, if I connect to
> 82.67.232.xxx, OpenVPN always answers with the other IP and therefore,
> the answer is sent via the default interface.
>
> I use OpenVPN 2.0rc12 (from Debian). Any idea ?
I had similar problem, it was saying it can not send. My setup is a
bit more complicated - [ISPs] <=> [Firewalls] <-- DNAT --> [Server]. In
this situation I DNAT connections to "virtual" IPs on the server and
use iproute2 rules to get the replies back. This was working great with
anything using TCP, DNS (UDP+TCP) and even GRE (yes, PPTP, I don't use
it any more) and so on, but failed with openvpn2's UDP mode. Since I'm
not sure if it's not my mistake I'll give this one more try when I have
some free time, but can someone give some light on this?
--
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
|
|
From: James Y. <ji...@yo...> - 2005-02-21 22:50:28
|
On Mon, 21 Feb 2005, Doncho N. Gunchev wrote: > On 2005-02-21 (Monday) 17:49, Vincent Bernat wrote: > > Hello ! > > > > I have a box with two Internet connections and I have an OpenVPN > > listening to all interfaces. I have a default route to one of the > > connections and I use iproute2 to ensure that what is sent with the > > address of the second connection is really sent to the second > > connection : > > > > 200: from 82.67.232.xxx lookup ADSL > > > > And in table ADSL : > > > > default via 82.67.232.254 dev eth2 > > > > Therefore, when I connect through ssh to 82.67.232.xxx, all is working > > fine, even if the default route uses another IP. ICMP and UDP are also > > working fine (I don't know the magic behind since they are > > connection-less). However, with OpenVPN, if I connect to > > 82.67.232.xxx, OpenVPN always answers with the other IP and therefore, > > the answer is sent via the default interface. > > > > I use OpenVPN 2.0rc12 (from Debian). Any idea ? > > I had similar problem, it was saying it can not send. My setup is a > bit more complicated - [ISPs] <=> [Firewalls] <-- DNAT --> [Server]. In > this situation I DNAT connections to "virtual" IPs on the server and > use iproute2 rules to get the replies back. This was working great with > anything using TCP, DNS (UDP+TCP) and even GRE (yes, PPTP, I don't use > it any more) and so on, but failed with openvpn2's UDP mode. Since I'm > not sure if it's not my mistake I'll give this one more try when I have > some free time, but can someone give some light on this? Someone wrote a patch to try to solve this, see the openvpn-devel archives. I haven't merged the patch yet as I was hoping there might be a more portable and/or simpler way of doing this. The problem is that the recvfrom syscall, which OpenVPN uses to read UDP packets, doesn't portably indicate which interface the packet came from. And the sendto syscall doesn't allow an interface or source address to be specified, only a dest address. So the sockets API doesn't seem to think through the ramifications of UDP-sendto via an INADDR_ANY bound socket. What about running two OpenVPN instances, one on each interface? James |
|
From: Neil B. <ne...@cs...> - 2005-02-21 23:39:47
|
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).
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.
NeilBrown
(*) In my case, the fact of multiple interfaces was entirely
co-incidental. It was sufficient to choose one, bind to that, and
then instead of a DNS entry:
openvpn.MY_DOMAIN CNAME somehost.MY_DOMAIN
I use
openvpn.MY_DOMAIN A NNN.NNN.NNN.NNN
|
|
From: Doncho N. G. <mr...@gl...> - 2005-02-23 10:06:12
|
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
|
|
From: Doncho N. G. <mr...@gl...> - 2005-02-23 09:46:22
|
On 2005 02 22 (Tuesday) 00:50, James Yonan wrote:
>
> On Mon, 21 Feb 2005, Doncho N. Gunchev wrote:
>
> > On 2005-02-21 (Monday) 17:49, Vincent Bernat wrote:
> > > Hello !
> > >
> > > I have a box with two Internet connections and I have an OpenVPN
> > > listening to all interfaces. I have a default route to one of the
...
> > I had similar problem, it was saying it can not send. My setup is a
> > bit more complicated - [ISPs] <=> [Firewalls] <-- DNAT --> [Server]. In
> > this situation I DNAT connections to "virtual" IPs on the server and
> > use iproute2 rules to get the replies back. This was working great with
> > anything using TCP, DNS (UDP+TCP) and even GRE (yes, PPTP, I don't use
> > it any more) and so on, but failed with openvpn2's UDP mode. Since I'm
> > not sure if it's not my mistake I'll give this one more try when I have
> > some free time, but can someone give some light on this?
>
> Someone wrote a patch to try to solve this, see the openvpn-devel
> archives.
>
> I haven't merged the patch yet as I was hoping there might be a more
> portable and/or simpler way of doing this.
>
> The problem is that the recvfrom syscall, which OpenVPN uses to read UDP
> packets, doesn't portably indicate which interface the packet came from.
> And the sendto syscall doesn't allow an interface or source address to be
> specified, only a dest address. So the sockets API doesn't seem to think
> through the ramifications of UDP-sendto via an INADDR_ANY bound socket.
>
> What about running two OpenVPN instances, one on each interface?
>
While possible, this leads to other problems - I can not monitor my VPN
clients (can't say this host has one of these IPs to Nagios), have to write
every firewall rule multiple times (and if we get connected to one more
IPS/Partner...) and must guess/check last client's IP if I need to ssh there.
Is it possible to bind openvpn (maybe 2.1) to multiple addresses like
BIND, SQUID, Apache and many others can? (btw: is that the reason DHCPD and
BIND do bind to all interfaces?)
PS: I *can* assign each VPN client additional unique IP, route it via
OpenVPN on connect and monitor that subnet but... it gets much more
complicated.
--
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
|
|
From: Charles D. <cd...@sp...> - 2005-02-23 10:00:29
|
On Wed, 23 Feb 2005 11:46:06 +0200, Doncho N. Gunchev wrote: > While possible, this leads to other problems - I can not monitor my VPN > clients (can't say this host has one of these IPs to Nagios) Eh? Can't Nagios support DNS? Script up your OpenVPN instances to register both reverse and forward DNS for connecting clients. > have to write every firewall rule multiple times (and if we get > connected to one more IPS/Partner...) Hrm? Not sure I follow. You're running both the OpenVPN instances on the same machine and same port; why would you need additional firewall rules? > must guess/check last client's IP if I need to ssh there. Once again, using dynamic DNS will fix this. > Is it possible to bind openvpn (maybe 2.1) to multiple addresses > like > BIND, SQUID, Apache and many others can? Sure you can bind to multiple addresses, but in UDP mode you don't have a guarantee that the answer will be on the same IP as the source. > PS: I *can* assign each VPN client additional unique IP, route it > via OpenVPN on connect and monitor that subnet but... it gets much > more complicated. I wouldn't bother. |
|
From: Doncho N. G. <mr...@gl...> - 2005-02-23 13:27:40
|
On 2005 02 23 (Wednesday) 12:01, Charles Duffy wrote:
> On Wed, 23 Feb 2005 11:46:06 +0200, Doncho N. Gunchev wrote:
...
> > Is it possible to bind openvpn (maybe 2.1) to multiple addresses
> > like
> > BIND, SQUID, Apache and many others can?
>
> Sure you can bind to multiple addresses, but in UDP mode you don't have a
> guarantee that the answer will be on the same IP as the source.
How does bind do so?
... netstat -unap | grep '[0-9]/named'
udp 0 0 127.0.0.1:53 0.0.0.0:* 6481/named
udp 0 0 10.0.0.1:53 0.0.0.0:* 6481/named
udp 0 0 192.168.1.1:53 0.0.0.0:* 6481/named
udp 0 0 172.30.255.200:53 0.0.0.0:* 6481/named
...
It is one process. If I guess this right it binds to many sockets and
sends replies via the socket it got the query from, just like when you
bind to only one interface(IP) you get replies fine (but I'm only guessing).
Is my guess right? Will in this case source be guaranteed?
--
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
|
|
From: James Y. <ji...@yo...> - 2005-02-23 20:06:33
|
On Wed, 23 Feb 2005, Doncho N. Gunchev wrote: > On 2005 02 23 (Wednesday) 12:01, Charles Duffy wrote: > > On Wed, 23 Feb 2005 11:46:06 +0200, Doncho N. Gunchev wrote: > ... > > > Is it possible to bind openvpn (maybe 2.1) to multiple addresses > > > like > > > BIND, SQUID, Apache and many others can? > > > > Sure you can bind to multiple addresses, but in UDP mode you don't have a > > guarantee that the answer will be on the same IP as the source. > > How does bind do so? > ... netstat -unap | grep '[0-9]/named' > udp 0 0 127.0.0.1:53 0.0.0.0:* 6481/named > udp 0 0 10.0.0.1:53 0.0.0.0:* 6481/named > udp 0 0 192.168.1.1:53 0.0.0.0:* 6481/named > udp 0 0 172.30.255.200:53 0.0.0.0:* 6481/named > ... > > It is one process. If I guess this right it binds to many sockets and > sends replies via the socket it got the query from, just like when you > bind to only one interface(IP) you get replies fine (but I'm only guessing). > Is my guess right? Will in this case source be guaranteed? Exactly -- we need to bind to multiple sockets, rather than to a single socket using the wildcard address INADDR_ANY as OpenVPN is doing right now. I didn't do it this way in the first place because I didn't realize that INADDR_ANY + UDP is broken due to the way that that the standard sockets API doesn't give you a source IP argument for the recvfrom and sendto syscalls. Listening on multiple sockets is also bad from a performance perspective unless you are using a modern polling API such as epoll on Linux 2.6. James |
|
From: Jamie L. <ja...@sh...> - 2005-02-24 00:21:24
|
James Yonan wrote: > Listening on multiple sockets is also bad from a performance perspective > unless you are using a modern polling API such as epoll on Linux > 2.6. That's only an issue if you have lots of interfaces. If you only have a few, poll() will be fine. But, if you're going to have a little non-portability, it's much easier to use the IP_PKTINFO method of getting the incoming destination address and interface (IP_PKTINFO with recvmsg/sendmsg). That has the advantage that you don't need to enumerate the interfaces, and you don't need to track interface changes: you can just use the received pktinfo struct for sending out the same interface, without interpreting it. -- Jamie |
|
From: James Y. <ji...@yo...> - 2005-02-24 10:03:26
|
On Thu, 24 Feb 2005, Jamie Lokier wrote: > James Yonan wrote: > > Listening on multiple sockets is also bad from a performance perspective > > unless you are using a modern polling API such as epoll on Linux > > 2.6. > > That's only an issue if you have lots of interfaces. > If you only have a few, poll() will be fine. > > But, if you're going to have a little non-portability, it's much > easier to use the IP_PKTINFO method of getting the incoming > destination address and interface (IP_PKTINFO with recvmsg/sendmsg). > > That has the advantage that you don't need to enumerate the > interfaces, and you don't need to track interface changes: you can > just use the received pktinfo struct for sending out the same > interface, without interpreting it. The NTP guys (another UDP server) had a bit of a low-grade burn over this: http://bugzilla.ntp.org/show_bug.cgi?id=314 It seems the anti-IP_PKTINFO camp won out? James |
|
From: Jamie L. <ja...@sh...> - 2005-02-24 15:54:15
|
James Yonan wrote: > The NTP guys (another UDP server) had a bit of a low-grade burn over this: > > http://bugzilla.ntp.org/show_bug.cgi?id=314 > > It seems the anti-IP_PKTINFO camp won out? The NTP maintainer rejected it in favour of scanning the list of interfaces and binding a UDP socket for each one. Largely because he wants to use a portable approach (I don't see how scanning the list of interfaces can be described as portable, but at least the code structure is common among implementations). But also some consideration of multicast, and NTP's baroque authentication came up. I have no idea how multicast interacts with IP_PKTINFO. Unfortunately, at the end of that thread, the problem of changing interfaces (or changing addresses on interfaces) was still broken. IP_PKTINFO works on Linux and sufficiently recent versions of Windows. There is some kind of BSD equivalent, but it's a bit different. It's quite simple to use: just copy the pktinfo from recvmsg() to sendmsg() and outgoing packets go out the same interface as the incoming. But it's not portable. For OpenVPN: I see just one thing to be careful of: you don't want packets coming on the wrong interface to be able to steal a VPN link until they've authenticated. In other words you need to treat distinct pktinfos in the same way that distinct source addresses are treated (or should be) for the purpose of updating the destination of outgoing tunnelled packets. It's not possible to solve this problem portably. (Of course, OpenVPN is not portable anyway because it depends on platform-specific tun/tap interfaces). But generally (beyond Linux, BSD and Windows 2003/XP), you will need to (1) structure the code to use multiple sockets; (2) read the list of local interfaces and local addresses on each (in a non-portable way unfortunately, and be aware it's a many-to-many relation, so sockets need to be bound to interfaces as well as local addresses where supported); (3) re-poll the list periodically to detect changes. That's quite a lot of work and still not fully portable (but it's the best you can do). However IP_PKTINFO (and the BSD equivalent) would fix the problem quickly and simply on the most used platforms, and probably performs better than multiple sockets on those platforms. -- Jamie |
|
From: James Y. <ji...@yo...> - 2005-02-24 19:47:44
|
On Thu, 24 Feb 2005, Jamie Lokier wrote: > James Yonan wrote: > > The NTP guys (another UDP server) had a bit of a low-grade burn over this: > > > > http://bugzilla.ntp.org/show_bug.cgi?id=314 > > > > It seems the anti-IP_PKTINFO camp won out? > > The NTP maintainer rejected it in favour of scanning the list of > interfaces and binding a UDP socket for each one. > > Largely because he wants to use a portable approach (I don't see how > scanning the list of interfaces can be described as portable, but at > least the code structure is common among implementations). > > But also some consideration of multicast, and NTP's baroque > authentication came up. I have no idea how multicast interacts with > IP_PKTINFO. > > Unfortunately, at the end of that thread, the problem of changing > interfaces (or changing addresses on interfaces) was still broken. > > IP_PKTINFO works on Linux and sufficiently recent versions of Windows. > There is some kind of BSD equivalent, but it's a bit different. > > It's quite simple to use: just copy the pktinfo from recvmsg() to > sendmsg() and outgoing packets go out the same interface as the > incoming. But it's not portable. > > For OpenVPN: I see just one thing to be careful of: you don't want > packets coming on the wrong interface to be able to steal a VPN link > until they've authenticated. Right, but that infrastructure is already there in the way that OpenVPN must decide the destination address of an outgoing UDP packet based on the source address of a previously received and authenticated packet. > In other words you need to treat distinct pktinfos in the same way > that distinct source addresses are treated (or should be) for the > purpose of updating the destination of outgoing tunnelled packets. Exactly. > It's not possible to solve this problem portably. (Of course, OpenVPN > is not portable anyway because it depends on platform-specific tun/tap > interfaces). True, there are a few areas where OpenVPN takes a lot of code to iron out differences between non-portable APIs, such as tun/tap, routing, and event polling. But these are critical areas that must be addressed because every OpenVPN configuration is using these APIs. IP_PKTINFO is not in the same category because it is only needed by people who want to run a UDP version of an OpenVPN server in a true multi-homed configuration. > But generally (beyond Linux, BSD and Windows 2003/XP), you will need > to (1) structure the code to use multiple sockets; (2) read the list > of local interfaces and local addresses on each (in a non-portable way > unfortunately, and be aware it's a many-to-many relation, so sockets > need to be bound to interfaces as well as local addresses where > supported); (3) re-poll the list periodically to detect changes. > > That's quite a lot of work and still not fully portable (but it's the > best you can do). > > However IP_PKTINFO (and the BSD equivalent) would fix the problem > quickly and simply on the most used platforms, and probably performs > better than multiple sockets on those platforms. I agree that IP_PKTINFO is the cleanest and easiest to implement in OpenVPN's case -- much more so than enumerating interfaces. James |
|
From: James Y. <ji...@yo...> - 2005-02-26 08:18:44
|
I've put together an IP_PKTINFO patch that deals with the UDP multihoming issue on Linux. The patch borrows from Neil Brown's original patch of 9 July 2004, but goes further by refactoring OpenVPN's basic address structures so that the actual local and remote addresses are always paired, and UDP responses to clients will always use the local source address which is associated with a given client instance object. The basic principle of operation is that any authentication test which would normally result in the remote address of a client being "remembered" in the client instance object state, will now also record the local address as well (when --multihome is enabled). So when the time comes to send packets to the client, if a local address has been associated with the client, it will be used as the source address on all outgoing packets. This should accomplish the basic goal of "Answering on the same interface where the request came from". The patch is here: http://openvpn.net/patch/ (with an 'MH' postfix) Apply the patch to a clean 2.0-rc16 tree, then: ./doclean autoreconf -i -v ./configure make To enable the UDP multi-homing feature, add a --multihome flag, and of course omit a --local directive. You'll know it's working when you see something like this: Peer Connection Initiated with 10.66.0.2:1194 (via 10.66.0.5) Please test and let me know if you find any bugs. This won't be going into 2.0, but will probably merge during the 2.1 beta series. James |
|
From: Martijn L. <m...@rt...> - 2005-02-24 22:17:02
|
Charles Duffy wrote: >On Wed, 23 Feb 2005 11:46:06 +0200, Doncho N. Gunchev wrote: > > > >>While possible, this leads to other problems - I can not monitor my VPN >>clients (can't say this host has one of these IPs to Nagios) >> >> > >Eh? Can't Nagios support DNS? Script up your OpenVPN instances to register >both reverse and forward DNS for connecting clients. > > It's not an DNS issue. Nagios does not use DNS, how can it work reliably if it did? But back to the problem. You just have to register a seperate host for each extra IP. Not elegant, works like a charm. HTH, M4 |
|
From: Charles D. <cd...@sp...> - 2005-02-25 23:52:52
|
On Thu, 24 Feb 2005 23:16:54 +0100, Martijn Lievaart wrote: >>Eh? Can't Nagios support DNS? Script up your OpenVPN instances to >>register both reverse and forward DNS for connecting clients. > > It's not an DNS issue. Nagios does not use DNS, how can it work reliably > if it did? You want to monitor whether the host with CN foo is up, but you don't know which OpenVPN instance that host will be connected to. You configure your OpenVPN instances to register foo.vpn.company.com in DNS whenever such a system connects, and have Nagios query the services not of 1.2.3.4 but rather of foo.vpn.company.com, which the DNS server will always redirect to the right place. What's so inherently unreliable on unworkable about this? It's literally what I do (I'm using homegrown network monitoring software rather than Nagios). |
|
From: Martijn L. <m...@rt...> - 2005-03-02 11:20:22
|
Charles Duffy wrote: >On Thu, 24 Feb 2005 23:16:54 +0100, Martijn Lievaart wrote: > > > >>>Eh? Can't Nagios support DNS? Script up your OpenVPN instances to >>>register both reverse and forward DNS for connecting clients. >>> >>> >>It's not an DNS issue. Nagios does not use DNS, how can it work reliably >>if it did? >> >> > >You want to monitor whether the host with CN foo is up, but you don't know >which OpenVPN instance that host will be connected to. You configure your >OpenVPN instances to register foo.vpn.company.com in DNS whenever such a >system connects, and have Nagios query the services not of 1.2.3.4 but >rather of foo.vpn.company.com, which the DNS server will always redirect >to the right place. What's so inherently unreliable on unworkable about >this? It's literally what I do (I'm using homegrown network monitoring >software rather than Nagios). > > > You are right, I misunderstood. Normally you don't want your nagios checked host to be resolved by DNS, if some local DNS breaks, it does not neccessaraly mean the host/service is broken. In this case however, using DNS is part of checking the service. M4 |
|
From: James Y. <ji...@yo...> - 2005-02-23 19:53:46
|
On Wed, 23 Feb 2005, Doncho N. Gunchev wrote: > On 2005 02 22 (Tuesday) 00:50, James Yonan wrote: > > > > On Mon, 21 Feb 2005, Doncho N. Gunchev wrote: > > > > > On 2005-02-21 (Monday) 17:49, Vincent Bernat wrote: > > > > Hello ! > > > > > > > > I have a box with two Internet connections and I have an OpenVPN > > > > listening to all interfaces. I have a default route to one of the > ... > > > I had similar problem, it was saying it can not send. My setup is a > > > bit more complicated - [ISPs] <=> [Firewalls] <-- DNAT --> [Server]. In > > > this situation I DNAT connections to "virtual" IPs on the server and > > > use iproute2 rules to get the replies back. This was working great with > > > anything using TCP, DNS (UDP+TCP) and even GRE (yes, PPTP, I don't use > > > it any more) and so on, but failed with openvpn2's UDP mode. Since I'm > > > not sure if it's not my mistake I'll give this one more try when I have > > > some free time, but can someone give some light on this? > > > > Someone wrote a patch to try to solve this, see the openvpn-devel > > archives. > > > > I haven't merged the patch yet as I was hoping there might be a more > > portable and/or simpler way of doing this. > > > > The problem is that the recvfrom syscall, which OpenVPN uses to read UDP > > packets, doesn't portably indicate which interface the packet came from. > > And the sendto syscall doesn't allow an interface or source address to be > > specified, only a dest address. So the sockets API doesn't seem to think > > through the ramifications of UDP-sendto via an INADDR_ANY bound socket. > > > > What about running two OpenVPN instances, one on each interface? > > > > While possible, this leads to other problems - I can not monitor my VPN > clients (can't say this host has one of these IPs to Nagios), have to write > every firewall rule multiple times (and if we get connected to one more > IPS/Partner...) and must guess/check last client's IP if I need to ssh there. > Is it possible to bind openvpn (maybe 2.1) to multiple addresses like > BIND, SQUID, Apache and many others can? (btw: is that the reason DHCPD and > BIND do bind to all interfaces?) SQUID and Apache are TCP servers. OpenVPN can also be a TCP server on multiple interfaces without issues. The problem is with UDP + INADDR_ANY (OpenVPN uses INADDR_ANY as a wildcard --local address when --local is not specified). It's possible that listening for UDP on multiple interfaces won't work correctly with INADDR_ANY, because the sendto syscall can't specify the interface or source address. The solutions is probably to allow a single OpenVPN process to listen on multiple sockets (2.1 wishlist). For now, it's best to just run multiple daemons. James |
|
From: Jamie L. <ja...@sh...> - 2005-02-27 02:32:00
|
James Yonan wrote: > So when the time comes to > send packets to the client, if a local address has been associated with > the client, it will be used as the source address on all outgoing packets. I presume the "last authenticated source address" is only used for tunnel packets - and that the packets which are part of an attempted authentication use the local address where the attempt is received instead? -- Jamie |
|
From: James Y. <ji...@yo...> - 2005-02-27 03:45:08
|
On Sun, 27 Feb 2005, Jamie Lokier wrote: > James Yonan wrote: > > So when the time comes to > > send packets to the client, if a local address has been associated with > > the client, it will be used as the source address on all outgoing packets. > > I presume the "last authenticated source address" is only used for > tunnel packets - and that the packets which are part of an attempted > authentication use the local address where the attempt is received instead? This is handled differently depending on mode. Because static key mode is stateless, the reply address is based on the last authenticated packet received and whether or not --float is used. In SSL/TLS mode, the initial P_CONTROL_HARD_RESET_CLIENT or P_CONTROL_HARD_RESET_SERVER message creates an untrusted client instance object and sets the reply address, which cannot change during the life of the session (if the client address changes, a new session must be negotiated). If --tls-auth is used, the reply address will not be learned from a packet unless it is verified by an HMAC integrity check. What this patch does is also learn the corresponding local IP address, any time a remote IP address is learned. James |
|
From: Christian S. <chr...@as...> - 2005-02-22 09:04:14
|
On Monday 21 February 2005 22:52, Doncho N. Gunchev wrote: > > I had similar problem, it was saying it can not send. My setup is a > bit more complicated - [ISPs] <=> [Firewalls] <-- DNAT --> [Server]. In > this situation I DNAT connections to "virtual" IPs on the server and > use iproute2 rules to get the replies back. This was working great with > anything using TCP, DNS (UDP+TCP) and even GRE (yes, PPTP, I don't use > it any more) and so on, but failed with openvpn2's UDP mode. Since I'm > not sure if it's not my mistake I'll give this one more try when I have > some free time, but can someone give some light on this? I have this same setup working for me. When using UDP as carrier for OpenVPN, and allowing connections via two internet lines, I run _two_ OpenVPN server instances. One for each internet line. Each server instance is bound (via 'local' parameter) to its own local ip alias (which the firewalls DNAT to). And I use iproute2 to source route based on these aliases. This works on both Linux and OpenBSD (although on OpenBSD 'pf' is used to source route). Christian |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X