voravit
Hi,
I have problem with the way the nexthop is added in OpenVPN due to the point-to-point link. I googled around and found many people ran into the same issue but didn't really find a solution. I would really appricate if someone could help me with this.
Here is my scenario:
I have two sites, each with two Internet connection to two different ISPs. The traffic from private networks behind each site should be routed across the Internet through a VPN server located in the third site. Each site has two VPN tunnels (tun0 over ISP1 and tun1 over ISP2) to the VPN server. If one link fails, all traffic should still go over the other link.
To achieve this, I need to have dynamic routing protocol instead of statically configure with route/iroute/push through VPN server. I use BGP on Quagga in this case and have a full-mesh peering (VPN server doesn't advertise anything though). The routing information in Quagga is exchanged correctly. However, the nexthop is always wrong because of the point-to-point link.
The IP address for the tunnel end-points are as follows:
VPN server
tun0 - 172.16.0.1
tun1 - 172.16.1.1
site1
tun0 - 172.16.0.2
tun1 - 172.16.1.2
site2
tun0 - 172.16.0.6
tun1 - 172.16.1.6
BGP peerings are up and running as follows:
over tun0
vpn server-site1 172.16.0.1<-->172.16.0.2
vpn server-site2 172.16.0.1<-->172.16.0.6
site1-site2 172.16.0.2<-->172.16.0.6
over tun1
vpn server-site1 172.16.1.1<-->172.16.1.2
vpn server-site2 172.16.1.1<-->172.16.1.6
site1-site2 172.16.1.2<-->172.16.1.6
site1 is announcing 192.168.1.0/24
site2 is announcing 192.168.2.0/24
vpn server does not announce anything
In Quagga,
site1 learns 192.168.2.0/24 from two peerings with nexthop 172.16.0.6 and 172.16.1.6 respectively
site2 learns 192.168.1.0/24 from two peerings with nexthop 172.16.0.2 and 172.16.1.2 respectively
vpn server learns both 192.168.1.0/24 and 192.168.2.0/24 from two peerings with nexthop as in site1 and site2 case.
But in the system routing table (from linux "route -n" command)
site1 can reach 192.168.2.0/24 via 172.16.0.5
site2 can reach 192.168.1.0/24 via 172.16.0.1
vpn server can reach 192.168.1.0/24 via 172.16.0.2 and 192.168.2.0/24 via 172.16.02
This is becuase quagga do recursive lookup for the nexthop,
Here is routing table in quagga (zebra process) on site1:
B>* 192.168.2.0/24 [200/0] via 172.16.0.6 (recursive via 172.16.0.1)
K>* 172.16.0.0/24 via 172.16.0.1, tun0
similarly on site2
B>* 192.168.1.0/24 [200/0] via 172.16.0.2 (recursive via 172.16.0.5)
K>* 172.16.0.0/24 via 172.16.0.5, tun0
With this settings, none of the sites can reach the private network (192.168.1.0/24 and 192.168.2.0/24)
Ping from site1 to 192.168.2.1 got no response. Tcpdump shows that ICMP echo request got to the VPN server but not to site2.
Ping from VPN server to 192.168.2.1 doesn't seem to reach site2 either. No ICMP echo request from tcpdump on tun0 on site2 but I can see ICMP echo request was sent from tcpdump on tun0 on the VPN server.
Ping from site2 to 192.168.1.1 got redirection error:
From 172.16.0.1: icmp_seq=1 Redirect Host(New nexthop: 172.16.0.2)
Any suggestion of what need to be done to get this routing to work correctly?
Best regards,
Voravit T.
Mimiko
What you want to achieve is the fault tollerant internet connection. This is not related to OpenVPN but rather to correct routing using iptables and ip rule. Search the internet for configuring with multiple gateways.
voravit
Hi, Mimiko
Thank you for your response (and sorry for my late reply).
With my current settings, the multiple gateway is working fine if you exclude the VPN part. The problem I had is when I tried to put it together with OpenVPN tunnels.
With OpenVPN, the routing information is congifured statically when a tunnel is established (through push/route/iroute configuration). This is added only the first time the tunnel is established. In my case, when I have two tunnels (tun0 and tun1), when both tunnels start up, the routing information from only one tunnel will be propagated to IP routing table on the machine and use for packet forwarding (say from tun0 for example). But if the tunnel0 goes down, this information remains the same and is not updated by OpenVPN server. So, I resorted to dynamic routing (through Quagga) to get the routing update automatically.
However, the issue is that OpenVPN has 172.16.0.0/24 allocated as the server, in which it will be used for point-to-point links for the clients. For example, tun0 on client1 uses 172.16.0.0/30 and tun0 on client2 uses 172.16.0.4/30. But the server will always uses the nexthop to both client1 and client2 as 172.16.0.2 (the server never have 172.16.0.5). On client1, the nexthop is 172.16.0.1 and client2 the nexthop is 172.16.0.5.
So, when I try to send an ICMP packet from client1 to client2, I will get a redirect error message since the server seems to send packet back to 172.16.0.2 and if I try to send an ICMP packet from client2 to client1, the server will never forward the packet (I suppose this is because the server sees the packet as if it destined to a machine on that link itself).
So, I am wondering if there is any possibility to make the server maintain routing information for each point-to-point separately in a normal manner (having each point-to-point link as local connected network). So, in my case, the server should use IP address 172.16.0.1 on the 172.16.0.0/30 for tun0 with client1 and IP address 172.16.0.5 for the 172.16.0.4/30 for tun0 with client2.
Best regards,
Voravit T.
Mimiko
If you want persistent IPs for clients, then use ccd files where for each client using its common name you will specify the IP address with ifconfig option.
voravit
I did have ccd configured with persistent IP addresses for clients (172.16.0.2 on client1 and 172.16.0.6 on client2)
The problem was on the server side that has only one IP address (172.16.0.1 only and not both 172.16.0.1 and 172.16.0.5).
Anyhow, I was pressed for time so in the end I resorted to a script to statically add and remove routes when switching active link between the tunnels (and skip route propagations through OpenVPN).
