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

Quan Tong Anh quanta.linux at gmail.com
Tue Oct 20 09:22:32 BST 2015


My boss pointed out the real error is:

> Oct 20 06:55:40 S2 vpn-local[31571]: S1/10.255.255.158:34602 MULTI: bad
source address from client [172.16.252.2], packet dropped

That explain why SNAT fix the problem.

Another option is using `iroute` as mentioned in the FAQ:
https://community.openvpn.net/openvpn/wiki/317-qmulti-bad-source-address-from-client--packet-droppedq-or-qget-inst-by-virt-failedq

On Tue, Oct 20, 2015 at 11:56 AM, Quan Tong Anh <quanta.linux at gmail.com>
wrote:

> I'm still confusing.
>
> I think that there should not be any NAT here.
>
> > Check the source IP on your PING with tcpdump.
>
> It's 172.16.252.2.
>
> > Use tcpdump and see whether the packet traverses tun1.
>
> Sure, yes. It even traverses tun0 (S1):
>
> ```
> tcpdump -vvv -i tun0 icmp -c 2
> tcpdump: listening on tun0, link-type RAW (Raw IP), capture size 65535
> bytes
> 04:54:00.192748 IP (tos 0x0, ttl 63, id 64168, offset 0, flags [DF], proto
> ICMP (1), length 84)
>     172.16.252.2 > 172.16.253.1: ICMP echo request, id 19385, seq 996,
> length 64
> 04:54:01.192501 IP (tos 0x0, ttl 63, id 64183, offset 0, flags [DF], proto
> ICMP (1), length 84)
>     172.16.252.2 > 172.16.253.1: ICMP echo request, id 19385, seq 997,
> length 64
> ```
>
> > Check iptables
>
> ```
> Chain FORWARD (policy DROP 0 packets, 0 bytes)
>  pkts bytes target     prot opt in     out     source
> destination
>   521 43764 ACCEPT     all  --  tun+   tun+    0.0.0.0/0
> 0.0.0.0/0
> ```
>
> > Check that ip forwarding is enabled on S1.
>
> Yes:
>
> ```
> cat /proc/sys/net/ipv4/ip_forward
> 1
> ```
>
> 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/423c906c/attachment-0001.html>


More information about the Quagga-users mailing list