On 10/14/2015 02:20 PM, Giancarlo Razzolini wrote:
Em 14-10-2015 10:31, C.L. Martinez escreveu:
Yes because sometimes I will need two or more tunX interfaces up
(created by openvpn or openconnect) or enc interface.
I think you are confusing gateways with default gateways.
No, but maybe I am explainning wrong ...
In the case of openconnect and openvpn, IP's are served by the
gateways (out of my control). With IPSec tunnels, I use fixed ips in
configuration files.
Either way, the VPN servers, normally, will be gateways for specific
networks, not the entire internet. So they are not "default" gateways.
Correct, but some of our customers had configured their openvpn servers
to route all traffic over their servers ..
All tunnels will be generated by this OpenBSD vm, not from my CentOS
host os.
From the point of view of the CentOS machine, your OpenBSD vm can
"reach" the internet and also the networks behind the VPN's. There is
one thing to remember though, if your VPN servers do not know how to get
back to your LAN network (the one your CentOS is), you'll need to use
nat on the OpenBSD firewall.
Exactly. I need to use NAT in this OpenBSD fw.
Well, due to this is a vm, I need to keep OpenBSD synced. Yes, I run
ntpd in this vm.
Well, you should always use ntpd. Not just because it's a vm.
But, ifstated is not need it in this scenario. If some of the tunnels
goes down, I will loose some connections, but other connections will
keep alive, for example DNS requests to our internal servers.
Meanwhile I don't loose default gateway in the primary routing table,
I can live with it.
Exactly why I said you're mixing gateways with default gateways. You
would use mpath if you have, lets say, two ISP's and you want your
OpenBSD machine to use both, for connections originating from it. Of
course mpath aren't used just for default gateways (0.0.0.0/0 routes).
Belive me: I am not confusing gateways with default gateways. For
example, using a free VPN connection, like vpnbook:
root@dundee:/var/log# netstat -rn -f inet
Routing tables
Internet:
Destination Gateway Flags Refs Use Mtu Prio
Iface
0/1 10.9.3.1 UGS 0 1 - 8
tun0
default 172.30.77.1 UGS 5 214405 - 8
vio1
10.9.0.1/32 10.9.3.1 UGS 0 0 - 8
tun0
10.9.3.1 10.9.3.2 UH 3 0 - 4
tun0
10.9.3.2 10.9.3.2 UHl 0 0 - 1
lo0
127/8 127.0.0.1 UGRS 0 0 32768 8
lo0
127.0.0.1 127.0.0.1 UHl 3 1956 32768 1
lo0
128/1 10.9.3.1 UGS 0 10 - 8
tun0
172.22.54.0/29 link#3 UC 0 0 - 4
vio2
172.22.54.6 52:54:00:78:64:85 UHLl 0 0 - 1
lo0
172.22.54.7 link#3 UHLb 0 0 - 1
vio2
172.22.55.0/28 link#1 UC 2 0 - 4
vio0
172.22.55.1 f2:d6:fa:0d:f3:4c UHLc 2 173062 - 4
vio0
172.22.55.2 52:54:00:1f:03:34 UHLc 0 2914 - 4
vio0
172.22.55.11 52:54:00:bf:1a:b6 UHLl 0 0 - 1
lo0
172.22.55.14 52:54:00:bf:1a:b6 UHLl 0 0 - 1
lo0
172.22.55.15 link#1 UHLb 0 0 - 1
vio0
172.22.56.0/29 link#4 UC 1 0 - 4
vio3
172.22.56.3 52:54:00:f5:51:26 UHLc 0 2 - 4
vio3
172.22.56.6 52:54:00:ba:da:27 UHLl 0 0 - 1
lo0
172.22.56.7 link#4 UHLb 0 0 - 1
vio3
172.22.57.0/29 link#5 UC 1 0 - 4
vio4
172.22.57.3 52:54:00:13:57:5f UHLc 0 7543 - 4
vio4
172.22.57.6 52:54:00:a2:86:ab UHLl 0 0 - 1
lo0
172.22.57.7 link#5 UHLb 0 0 - 1
vio4
172.22.58.0/29 link#6 UC 1 0 - 4
vio5
172.22.58.1 52:54:00:4b:fd:a4 UHLl 0 0 - 1
lo0
172.22.58.2 60:be:b5:30:5b:d2 UHLc 2 5414 - 4
vio5
172.22.58.7 link#6 UHLb 0 0 - 1
vio5
172.30.77.0/29 link#2 UC 1 0 - 4
vio1
172.30.77.1 fe:54:00:16:db:3c UHLc 2 0 - 4
vio1
172.30.77.6 52:54:00:16:db:3c UHLl 0 0 - 1
lo0
172.30.77.7 link#2 UHLb 0 0 - 1
vio1
176.126.237.217/32 172.30.77.1 UGS 1 22518 - 8
vio1
224/4 127.0.0.1 URS 0 0 32768 8 lo0
ALL traffic is routed over tun0 interface. Some of our customers use the
same type of configuration. This is my actual problem: discriminate when
I do requests to my customers and when I do requests to our internal
lans. I need my default gw untouched in this OpenBSD fw.
If you have, lets say, two tunnels that give you access to the same
network, you could use mpath and add two routes to it, using different
gateways. If they have the same routing priority, OpenBSD would
round-robin between them. This is where ifstated can be used, to detect
failures and add/remove the routes as needed.
This last scenario is not possible: all networks have different address.
Thanks Giancarlo.
