Hi Dave,
On 01.08.14 23:29 CEST, davidg12...@fast-email.com wrote:
>> Keep thinking of the OpenVPN setup as just 2 routers with a fixed Ethernet
>> cable in between.
>> That in reality the "ethernet cable" is a VPN tunnel does not change the
>> routing setup.
>
> I guess that might be some of my problem.
>
> I've been thinking of it as 2 wires, not 1 (I like to think with diagrams
> ...)
>
> /-- eth1 -- internet -- ext1 --\
> eth0 -- Loc1 --| | -- Loc2 -- eth0 -- lan
> -- eth0 -- SvcX
> (server) \-- tun1 ----- vpn ---- tun1 --/ (client)
>
> and that traffic can flow any number of ways, over differet routes. And my
> job is to tell it all when to travel over which wire.
>
> For example, this
>
> SvcX:eth0 --> Loc2:eth0 --> Loc2:eth1 -> internet
>
> versus
>
> SvcX:eth0 --> Loc2:eth0 --> Loc2:tun1 -> vpn -> Loc1:tun1 -> Loc1:eth1
> -> internet
>
> and, of course, 'backwards' for both.
Yes, that's more or less correct, however you can usually define only
the rule for the next hop and not for the whole path.
The process you have described is called "routing". ;)
Maybe a small hands-on helps to understand the process better:
Assume two routers:
- router A ("local") has internet IP 198.51.100.2/24 and
- a local network 192.168.0.0/24
- router B ("remote") has internet IP 203.0.113.2/24 and
- a local network 192.168.123.0/24
If you type on the local router:
$ /sbin/route -n
you'll get something like this (on a linux box / on BSDs: netstat -nr)
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref Use Iface
> 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
> 198.51.100.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
> 0.0.0.0 198.51.100.1 0.0.0.0 UG 0 0 0 eth1
That's my routing table before I connect to an OpenVPN server.
Let's start a test instance on a remote linux server 203.0.113.2:
$ openvpn --dev tun --ifconfig 10.0.0.1 10.0.0.2
This starts a simple openvpn (in p2p mode - w/o certificates, etc.).
WARNING: DO NOT USE THIS IN PRODUCTION - NO ENCRYPTION IS BEING USED!
The remote "server" gets the 10.0.0.1, the local "client" the 10.0.0.2!
Now, let's connect to that remote server (swap --ifconfig addresses!):
$ openvpn --dev tun --ifconfig 10.0.0.2 10.0.0.1 --remote 203.0.113.2
^^ ^^
The routing table contains now another *host* route for 10.0.0.1 -
that one was added by openvpn and let you ping the remote host trough
the tunnel.
> $ /sbin/route -n
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref Use Iface
> 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
> 198.51.100.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
> 0.0.0.0 198.51.100.1 0.0.0.0 UG 0 0 0 eth1
> 10.0.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
At this point all packets to 192.168.123.0/24 (which is behind the
remote router) are still being routed via the default route since there
is no other rule for that network.
Now change the openvpn commands to add routes for the two subnets:
$ openvpn --dev tun --ifconfig 10.0.0.1 10.0.0.2 \
--route 192.168.0.0 255.255.255.0
and on the local router:
$ openvpn --dev tun --ifconfig 10.0.0.2 10.0.0.1 --remote 203.0.113.2 \
--route 192.168.123.0 255.255.255.0
After re-connect you should have another entry in the routing table at
both routers:
> $ /sbin/route -n
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref Use Iface
> 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
> 198.51.100.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
> 0.0.0.0 198.51.100.1 0.0.0.0 UG 0 0 0 eth1
> 10.0.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
> 192.168.123.0 10.0.0.1 255.255.255.0 UG 0 0 0 tun0
(at the remote router it should look similar)
If you ping between two hosts on the subnets, e.g. from 192.168.0.11:
> $ ping -c 1 192.168.123.22
> PING 192.168.123.22 (192.168.123.22) 56(84) bytes of data.
> 64 bytes from 192.168.123.22: icmp_req=1 ttl=63 time=39.1 ms
>
> --- 192.168.123.22 ping statistics ---
> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> rtt min/avg/max/mdev = 39.150/39.150/39.150/0.000 ms
that traffic is routed through the tunnel, because the route for
192.168.123.0/24 is more specific than 0.0.0.0/0 (larger netmask).
In this example (mode p2p) we need no iroute, openvpn knows where to
send the traffic - because there is only one peer (compared to
client/server mode where can have multiple clients).
The "--route" parameters just tell openvpn to add the routing
entries/rules, you could also do it manually or by using a connect script.
>> Yup, but that is only because OpenVPN needs to know TOO where to drop stuff
>> once it comes in.
>
> So Openvpn is not CREATING those routes? We're just telling it about
> EXISTING routes that have to have already been set up on each involved box/OS?
The actual routing is done by the OS - but openvpn make it easy to
configure the routing (it just executes the "route add ..." commands).
>> I usually handle that with iroute lines** in the client config file I have
>> in the ccd directory. OpenVPN
>> sees the iroute lines and makes sure the OS it is running on gets updates
>> too. Having a config file per
>> client in a separate directory is an easy way to keep track of what is
>> where, for me, and is a standard
>> way for OpenVPN.
>
> So breaking this down piece by piece, to do THAT^ I need related entries in
> all of these
>
> Loc1
> /etc/openvpn/loc2.server.conf
> /etc/openvpn/ccd/loc1.client.conf
> /etc/sysconfig/network/ifroute-eth1
> /etc/sysconfig/network/ifroute-eth0
>
> Loc2
> /etc/sysconfig/network/ifroute-eth1
> /etc/sysconfig/network/ifroute-eth0
>
> making sure that the openvpn config data matches what's on the OS in the
> ifroute-* stuff.
>
> Is that right?
>
> I guess I could put the 'ip route add ...' commands in Openvpn up/down
> scripts. Don't yet know if that's better than the ifroute-*.
I guess those /etc/sysconfig/network/ifroute* are part of your
distribution and executed when you do something like "ifup eth1" and
during boot time.
That's not really related to your openvpn setup.
>> The majority of the clients have no network behind them that need to be
>> reachable, so they have no
>> iroute statements.
>
> Both ends of mine have lans.
The iroute config is only needed on the server side (in the ccd config).
As mentioned above, a server can have multiple clients, and, thus needs
to know which client hosts a particular subnet.
>> Some have an iroute line like: iroute 172.16.17.0/24
>
>> This way the OpenVPN servers knows that behind that client is a network and
>> that all traffic for those
>> ip-numbers needs to be sent to that client. That client will then handle the
>> rest of the routing.
>
> "handle the rest" means -- Openvpn config will handle it? IIuc --> no. The
> OS configs will. Right?
??? (it's getting more and more confusing ...)
[...]
>> and static routes. Just use static routes when there are only a few
>> connections and all go through the OpenVPN server. I have a setup where the
>> OpenVPN link is just one of the links between sites.
>
> Where/how are you setting up your OS static routes? Are those routes set up
> and in existence before OpenVPN is started, via OS's network config files?
I'm used to set all openvpn related routes in the openvpn config and
others in the OS network config (/etc/network/interfaces on Debian).
HTH,
Mathias.
------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
