[quagga-users 14158] Re: Routing over OpenVPN - cannot ping the other side?

Quan Tong Anh quanta.linux at gmail.com
Mon Oct 19 18:17:31 BST 2015


I solved the problem by adding a rule to NAT traffic that coming from C,
and go through the S1:

```
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source
destination
    0     0 MASQUERADE  all  --  *      *       172.16.252.0/24
0.0.0.0/0
```

```
quagga-router at openvpn-client-1# sh interface  tun1
Interface tun1 is up, line protocol detection is disabled
  Description: vpn-client-to-cats
  index 9 metric 1 mtu 1500
  flags: <UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>
  inet 172.16.252.2/24 broadcast 172.16.252.255
  inet 172.16.252.2/32

quagga-router at openvpn-client-1# ping 172.16.253.1
PING 172.16.253.1 (172.16.253.1) 56(84) bytes of data.
64 bytes from 172.16.253.1: icmp_seq=1 ttl=63 time=2.22 ms
64 bytes from 172.16.253.1: icmp_seq=2 ttl=63 time=1.82 ms
64 bytes from 172.16.253.1: icmp_seq=3 ttl=63 time=3.70 ms
```

On Mon, Oct 19, 2015 at 8:03 PM, Michael Moffatt <michael at moffatt.org.nz>
wrote:

> Check the source IP on your PING with tcpdump.
> Use tcpdump and see whether the packet traverses tun1.
> Check the openvpn traffic rules (I don't know anything about openvpn
> config).
> Check iptables.
> Check that ip forwarding is enabled on S1.
>
>
> On 19/10/15 06:43, Quan Tong Anh wrote:
>
> - Ubuntu 14.04
> - Quagga 0.99.22.4
> - OpenVPN 2.3.2-7
>
> The diagram:
>
> C ---> S1 --> S2
>
> S1: C's openvpn server (172.16.252.1) and S2's openvpn client
> (172.16.253.2)
> S2: openvpn server, 172.16.253.1
> C: S1's openvpn client ,172.16.252.2
>
> Quagga is intalled on 3 servers, an IP address is advertised via the
> loopback interface as belows:
>
> C: 10.255.250.4
> S1: 10.255.250.2
> S2: 10.255.250.1
>
> `sh ip ospf neighbor` in C:
>
> Neighbor ID Pri State Dead Time Address Interface RXmtL RqstL DBsmL
> 10.255.250.2 1 Full/DROther 30.845s 172.16.252.1 tun0:172.16.252.2 0 0 0
>
> S1:
>
> Neighbor ID Pri State Dead Time Address Interface RXmtL RqstL DBsmL
> 10.255.250.4 1 Full/DROther 31.851s 172.16.252.2 tun0:172.16.252.1 0 0 0
> 10.255.250.1 1 Full/DROther 33.188s 172.16.253.1 tun1:172.16.253.2 0 0 0
>
> S2:
>
> Neighbor ID Pri State Dead Time Address Interface RXmtL RqstL DBsmL
> 10.255.250.2 1 Full/DROther 38.549s 172.16.253.2 tun0:172.16.253.1 0 0 0
>
> `sh ip route` in C:
>
> ```
> Codes: K - kernel route, C - connected, S - static, R - RIP,
>        O - OSPF, I - IS-IS, B - BGP, A - Babel,
>        > - selected route, * - FIB route
>
> K>* 0.0.0.0/0 via 10.255.255.129, eth0
> O>* 10.255.250.1/32 [110/30] via 172.16.252.1, tun0, 2d00h30m
> O>* 10.255.250.2/32 [110/20] via 172.16.252.1, tun0, 2d00h30m
> C>* 10.255.250.4/32 is directly connected, lo
> C>* 10.255.255.128/25 is directly connected, eth0
> C>* 127.0.0.0/8 is directly connected, lo
> O   172.16.252.0/24 [110/10] is directly connected, tun0, 2d01h14m
> C>* 172.16.252.0/24 is directly connected, tun0
> O   172.16.252.4/32 [110/10] is directly connected, tun0, 2d01h14m
> C>* 172.16.252.4/32 is directly connected, tun0
> O>* 172.16.253.0/24 [110/20] via 172.16.252.1, tun0, 2d00h30m
> ```
>
> S1:
>
> ```
> Codes: K - kernel route, C - connected, S - static, R - RIP,
>        O - OSPF, I - IS-IS, B - BGP, A - Babel,
>        > - selected route, * - FIB route
>
> K>* 0.0.0.0/0 via 10.255.255.129, eth0
> O>* 10.255.250.1/32 [110/20] via 172.16.253.1, tun1, 2d16h54m
> O   10.255.250.2/32 [110/10] is directly connected, lo, 2d17h06m
> C>* 10.255.250.2/32 is directly connected, lo
> C>* 10.255.255.128/25 is directly connected, eth0
> C>* 127.0.0.0/8 is directly connected, lo
> O   172.16.252.0/24 [110/10] is directly connected, tun0, 2d17h06m
> C>* 172.16.252.0/24 is directly connected, tun0
> O>* 172.16.252.4/32 [110/20] via 172.16.252.2, tun0, 2d16h54m
> O   172.16.253.0/24 [110/10] is directly connected, tun1, 2d17h06m
> C>* 172.16.253.0/24 is directly connected, tun1
> C>* 172.16.253.2/32 is directly connected, tun1
> ```
>
> S2:
>
> ```
> Codes: K - kernel route, C - connected, S - static, R - RIP,
>        O - OSPF, I - IS-IS, B - BGP, A - Babel,
>        > - selected route, * - FIB route
>
> K>* 0.0.0.0/0 via 10.255.255.129, eth0
> O   10.255.250.1/32 [110/10] is directly connected, lo, 00:00:11
> C>* 10.255.250.1/32 is directly connected, lo
> O>* 10.255.250.2/32 [110/20] via 172.16.253.2, tun0, 00:00:03
> C>* 10.255.255.128/25 is directly connected, eth0
> C>* 127.0.0.0/8 is directly connected, lo
> O>* 172.16.252.0/24 [110/20] via 172.16.253.2, tun0, 00:00:03
> O>* 172.16.252.4/32 [110/30] via 172.16.253.2, tun0, 00:00:03
> O   172.16.253.0/24 [110/10] is directly connected, tun0, 00:00:11
> C>* 172.16.253.0/24 is directly connected, tun0
> C>* 172.16.253.1/32 is directly connected, tun0
> ```
>
> From C, I can ping tun1-S1 (vpn client of S2):
>
> ```
> ping -c 2 172.16.253.2
> PING 172.16.253.2 (172.16.253.2) 56(84) bytes of data.
> 64 bytes from 172.16.253.2: icmp_seq=1 ttl=64 time=0.750 ms
> 64 bytes from 172.16.253.2: icmp_seq=2 ttl=64 time=0.732 ms
> ```.
>
> But I cannot ping S2:
>
> ```
> ping -c 2 172.16.253.1
> PING 172.16.253.1 (172.16.253.1) 56(84) bytes of data.
> ^C
> --- 172.16.253.1 ping statistics ---
> 2 packets transmitted, 0 received, 100% packet loss, time 1008ms
> ```
>
> What is the problem? Is there something wrong with my setup?
>
>
> _______________________________________________
> Quagga-users mailing listQuagga-users at lists.quagga.nethttps://lists.quagga.net/mailman/listinfo/quagga-users
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quagga.net/pipermail/quagga-users/attachments/20151020/aebf75e3/attachment-0001.html>


More information about the Quagga-users mailing list