LinuxQuestions.org - Route and OpenVPN problem

- Linux - Networking (https://www.linuxquestions.org/questions/linux-networking-3/)

- - Route and OpenVPN problem (https://www.linuxquestions.org/questions/linux-networking-3/route-and-openvpn-problem-4175597149/)

Route and OpenVPN problem

Hi,

I meet an terrible issue with routes and OpenVPN. Below is my design:

Network 172.16.2.0/24<====>Linux Box<====>Vyatta<====>Network 172.16.4.0/24

My goal is to create the communication between network 172.16.2.0/24 and network 172.16.4.0/24 so I created a VPN between the Linux Box and Vyatta.

I used an OpenVPN server on Linux Box with this config:

Code:

port 1197

proto udp

dev tun3

ca ca.crt

cert server.crt

key server.key

dh dh1024.pem

server 10.8.24.0 255.255.255.0

push "route 172.16.2.0 255.255.255.0"

route 172.16.4.0 255.255.255.0

status openvpn-status.log

keepalive 10 120

comp-lzo

persist-key

persist-tun

verb 3

On the Vyatta side, I used this config:

Code:

openvpn vtun3 {

    mode client

    openvpn-option --comp-lzo

    remote-host X.X.X.X

    remote-port 1197

    tls {

        ca-cert-file ca.crt

        cert-file mycert.crt

        key-file mykey.key

    }

The VPN is connected correctly and I can see its status in openvpn-status.log.

Now when I try the connectivity, I have some troubles:
Test 1 - from Vyatta to network 172.16.2.0/24: it works
Test 2 - from Linux Box to network 172.16.4.0/24: it doesn't work
Test 3 - from network 172.16.4.0/24 to network 172.16.2.0/24: it doesn't work

I did some trace in order to find out the issue.

Test 1: tcpdump on Vyatta

Code:

13:50:51.540985 IP 10.8.24.6 > 172.16.2.66: ICMP echo request, id 12158, seq 1, length 64

13:50:51.571067 IP 172.16.2.66 > 10.8.24.6: ICMP echo reply, id 12158, seq 1, length 64

13:50:52.542148 IP 10.8.24.6 > 172.16.2.66: ICMP echo request, id 12158, seq 2, length 64

13:50:52.569989 IP 172.16.2.66 > 10.8.24.6: ICMP echo reply, id 12158, seq 2, length 64

Test 2: tcpdump on the Linux Box

Code:

12:52:32.288776 IP 10.8.24.1 > 172.16.4.2: ICMP echo request, id 18473, seq 1, length 64

12:52:33.288937 IP 10.8.24.1 > 172.16.4.2: ICMP echo request, id 18473, seq 2, length 64

12:52:34.288838 IP 10.8.24.1 > 172.16.4.2: ICMP echo request, id 18473, seq 3, length 64

12:52:35.288798 IP 10.8.24.1 > 172.16.4.2: ICMP echo request, id 18473, seq 4, length 64

Strangely, I have nothing on the tcpdump on Vyatta with this test.

Test 3: tcpdump on Vyatta

Code:

13:55:01.533122 IP 172.16.4.2 > 172.16.2.1: ICMP echo request, id 51096, seq 1, length 64

13:55:02.533125 IP 172.16.4.2 > 172.16.2.1: ICMP echo request, id 51096, seq 2, length 64

13:55:03.533075 IP 172.16.4.2 > 172.16.2.1: ICMP echo request, id 51096, seq 3, length 64

13:55:04.533149 IP 172.16.4.2 > 172.16.2.1: ICMP echo request, id 51096, seq 4, length 64

Again, I have nothing on the tcpdump on the Linux Box with this test.

On the Linux Box, I have the correct route: (I removed all unnecessary routes on the output below)

Code:

[root@LinuxBox openvpn]# ip route

10.8.24.2 dev tun3  proto kernel  scope link  src 10.8.24.1

10.8.24.0/24 via 10.8.24.2 dev tun3

172.16.4.0/24 via 10.8.24.2 dev tun3

172.16.2.0/24 dev eth2  proto kernel  scope link  src 172.16.2.110

Same on the Vyatta:

Code:

root@vyatta:/# ip route

10.8.24.1 via 10.8.24.5 dev vtun3

10.8.24.5 dev vtun3  proto kernel  scope link  src 10.8.24.6

172.16.2.0/24 via 10.8.24.5 dev vtun3

172.16.4.0/24 dev eth1  proto kernel  scope link  src 172.16.4.1

Do you have any clue why I cannot make those 2 networks communicate together?
I really don't understand why I cannot see anything on the opposite side when I do test 2 and test 3. Do you have any idea?

Thank you for your help

PS: sorry for the long post.

Use traceroute from both ends to test the round-trip connection to IP addresses on the other side of the tunnel.

Connection issues are usually traceable to omitted routing rules, because a successfully-connected tunnel-mode OpenVPN behaves just like any other router.

With your setup, check both 10.8.0.x and 172.16.4.x addresses.

Expect to see traceroute to "drop dead and start printing rows of asterisks," indicating a return-routing problem at that "hop."

Thanks sundialsvcs for your answer.

I tried to do a traceroute as you suggested:
- From the Linux Box:

Code:

traceroute 172.16.4.1

traceroute to 172.16.4.1 (172.16.4.1), 30 hops max, 40 byte packets

 1  * * *

 2  * * *

 3  * * *

 4  * * *

 5  * * *

 6  * * *

 7  * * *

 8  * * *

 9  * * *

10  * * *

11  * * *

12  * * *

13  * * *

14  * * *

15  * * *

16  * * *

17  * * *

18  * * *

19  * * *

20  * * *

21  * * *

22  * * *

23  * * *

24  * * *

25  * * *

26  * * *

27  * * *

28  * * *

29  * * *

30  * * *

This result doesn't make sense as I have all correct routes on this machine (see my first post).
So I tried a traceroute to the other end of the tunnel and everything is fine:

Code:

traceroute 10.8.24.6

traceroute to 10.8.24.6 (10.8.24.6), 30 hops max, 40 byte packets

 1  10.8.24.6 (10.8.24.6)  27.832 ms  27.980 ms  28.119 ms

- From Vyatta:

Code:

traceroute 172.16.2.66

traceroute to 172.16.2.66 (172.16.2.66), 30 hops max, 60 byte packets

 1  10.8.24.1 (10.8.24.1)  27.707 ms  27.820 ms  27.922 ms

 2  172.16.2.66 (172.16.2.66)  29.980 ms  30.002 ms  30.249 ms

Everything is fine on this side.

Do you have any other ideas?

Hi,

I think you need to have specific routes on hosts on your networks.

On hosts on network 172.16.4.0/24
to 172.16.2.0/24 via Vyatta

On hosts on network 172.16.2.0/24
to 172.16.4.0/24 via Linux Box

The first part of the puzzle is to be sure that the OpenVPN client/server processes are able to send and receive encrypted packets with one another. Every computer along any possible route must have routing commands to cover both the outbound and return routes, or they might simply all throw the packets up through the default-route to a central router that knows what to do.

The second part is to make sure that packets from the "VPN-to-VPN network" (usually 10.8.0.x) will be correctly routed back to the OpenVPN machines "as a gateway."

The third step (which is common with any other type of router) is to be sure that remote subnet addresses are also set to use the appropriate OpenVPN machine as a gateway ... and that you have a ccd directory with iroute commands to enable OpenVPN to know about these subnets and to know which remote is responsible for each of them.

In all cases, it isn't enough to make sure that traffic gets to the proper destination: the replies must also get back. (If traceroute "drops dead" at some hop and starts printing asterisks, then it means that the reply from that hop didn't make it home. A route was found to that hop, but the reply that should have been sent back was lost. It probably defaulted to a router which sent it to the Internet, which promptly squashed it as it does to all "non-routable addresses.")