Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I have an Ubuntu 12.04 LTE virtual server, kernel 2.6.32, and a VPN with VTun running.

In the VPN, the server is 6.6.6.6, and the two clients are 6.6.6.29 and 6.6.6.35.

If I ping 6.6.6.6 from any client, the server responds immediately. So I believe clients are configured correctly. BUT if I ping 6.6.6.35 from 6.6.6.29, or viceversa, there’s no response.

A traceroute from 6.6.6.29 says:

$ traceroute -n 6.6.6.35

traceroute to 6.6.6.35 (6.6.6.35), 30 hops max, 60 byte packets
 1  6.6.6.6  78.409 ms  80.202 ms  82.820 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *

I guess there is a routing problem in the routing tables of the server.

My config files are:

$ cat /etc/default/vtun

RUN_SERVER=yes

$ cat /etc/vtund.conf

options {
    bindaddr {
        addr 85.84.83.82;
    };
}

default {
    type      tun;
    proto     tcp;
    persist   yes;
    keepalive yes;
    stat      yes;
    multi     yes;
}

client1 {
    passwd   U'dLikeToKnow;

    up {
        ifconfig "%% 6.6.6.6 pointopoint 6.6.6.29 mtu 1450";
        route "add -net 6.6.6.0 netmask 255.255.255.0 gw 6.6.6.29";
    };
    down {
        ifconfig "%% down";
        route "del -net 6.6.6.0 netmask 255.255.255.0 gw 6.6.6.29";
    };
}

client2 {
    passwd   U'dLikeToKnow;

    up {  
        ifconfig "%% 6.6.6.6 pointopoint 6.6.6.35 mtu 1450";
        route "add -net 6.6.6.0 netmask 255.255.255.0 gw 6.6.6.35";
    };
    down {
        ifconfig "%% down";
        route "del -net 6.6.6.0 netmask 255.255.255.0 gw 6.6.6.35";
    };
}     

$ ifconfig

tun0      Link encap:UNSPEC  direcciónHW 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          Direc. inet:6.6.6.6  P-t-P:6.6.6.29  Másc:255.255.255.255
          ACTIVO PUNTO A PUNTO FUNCIONANDO NOARP MULTICAST  MTU:1450  Métrica:1
          Paquetes RX:358 errores:0 perdidos:0 overruns:0 frame:0
          Paquetes TX:18 errores:0 perdidos:0 overruns:0 carrier:0
          colisiones:0 long.colaTX:500 
          Bytes RX:27624 (27.6 KB)  TX bytes:1560 (1.5 KB)

tun1      Link encap:UNSPEC  direcciónHW 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          Direc. inet:6.6.6.6  P-t-P:6.6.6.35  Másc:255.255.255.255
          ACTIVO PUNTO A PUNTO FUNCIONANDO NOARP MULTICAST  MTU:1450  Métrica:1
          Paquetes RX:98 errores:0 perdidos:0 overruns:0 frame:0
          Paquetes TX:91 errores:0 perdidos:0 overruns:0 carrier:0
          colisiones:0 long.colaTX:500 
          Bytes RX:10580 (10.5 KB)  TX bytes:8579 (8.5 KB)

$ route

Tabla de rutas IP del núcleo
Destino         Pasarela        Genmask         Indic Métric Ref    Uso Interfaz
6.6.6.29        *               255.255.255.255 UH    0      0        0 tun0
6.6.6.35        *               255.255.255.255 UH    0      0        0 tun1
6.6.6.0         6.6.6.35        255.255.255.0   UG    0      0        0 tun1
6.6.6.0         6.6.6.29        255.255.255.0   UG    0      0        0 tun0
127.0.0.0       *               255.0.0.0       U     0      0        0 lo
default         *               0.0.0.0         U     0      0        0 venet0

But the strangest thing is that this problem appeared when I upgraded the server from version 10.04 LTE to 12.04 LTE.

When I do: # cat /proc/sys/net/ipv4/ip_forward I get 1

When I do: # ufw I get -bash: ufw: command not found

ADDED 15/apr/2013:

When I do: # iptables -L I get:

Chain INPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED
REJECT     tcp  --  anywhere             anywhere             tcpflags:! FIN,SYN,RST,ACK/SYN reject-with tcp-reset
DROP       all  --  anywhere             anywhere             state INVALID
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:8443
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:8880
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:http
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:https
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:ftp
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:ssh
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:smtp
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:ssmtp
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:pop3
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:pop3s
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:imap2
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:imaps
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:poppassd
DROP       tcp  --  anywhere             anywhere             tcp dpt:mysql
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:postgresql
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:9008
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:9080
ACCEPT     udp  --  anywhere             anywhere             udp dpt:netbios-ns
ACCEPT     udp  --  anywhere             anywhere             udp dpt:netbios-dgm
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:netbios-ssn
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:microsoft-ds
ACCEPT     udp  --  anywhere             anywhere             udp dpt:openvpn
DROP       udp  --  anywhere             anywhere             udp dpt:domain
DROP       tcp  --  anywhere             anywhere             tcp dpt:domain
ACCEPT     icmp --  anywhere             anywhere             icmptype 8 code 0
ACCEPT     all  --  anywhere             anywhere            

Chain FORWARD (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED
REJECT     tcp  --  anywhere             anywhere             tcpflags:! FIN,SYN,RST,ACK/SYN reject-with tcp-reset
DROP       all  --  anywhere             anywhere             state INVALID
ACCEPT     all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            

Chain OUTPUT (policy DROP)
target     prot opt source               destination         
LOG        all  --  anywhere            !6.6.6.0/24           limit: avg 5/min burst 5 LOG level warning
LOG        all  --  anywhere            !6.6.6.0/24           limit: avg 5/min burst 5 LOG level warning
ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED
REJECT     tcp  --  anywhere             anywhere             tcpflags:! FIN,SYN,RST,ACK/SYN reject-with tcp-reset
DROP       all  --  anywhere             anywhere             state INVALID
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere   

If I do tcpdump -n -vvv -i tun0, and I ping 6.6.6.35 from 6.6.6.29 I get:

tcpdump: listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes
00:17:16.876853 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    6.6.6.29 > 6.6.6.35: ICMP echo request, id 4664, seq 1, length 64
00:17:17.875252 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    6.6.6.29 > 6.6.6.35: ICMP echo request, id 4664, seq 2, length 64
00:17:18.882941 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    6.6.6.29 > 6.6.6.35: ICMP echo request, id 4664, seq 3, length 64
00:17:19.891173 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    6.6.6.29 > 6.6.6.35: ICMP echo request, id 4664, seq 4, length 64
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel

And if at the same time I do tcpdump -n -vvv -i tun1, I wait and wait and I get nothing:

tcpdump: listening on tun1, link-type RAW (Raw IP), capture size 65535 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel

When I do tcpdump -n -vvv -e -i any host 6.6.6.29 I get:

tcpdump -n -vvv -e -i any host 6.6.6.29
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
09:50:05.051513  In ethertype IPv4 (0x0800), length 100: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    6.6.6.29 > 6.6.6.35: ICMP echo request, id 11932, seq 1, length 64

And when I do ip route get 6.6.6.35 from 6.6.6.29 iif tun0 I get:

6.6.6.35 from 6.6.6.29 dev tun1  src 6.6.6.6 
    cache <src-direct>  mtu 1450 advmss 1410 hoplimit 64 iif tun0

Any suggestions?

share|improve this question

1 Answer 1

up vote 1 down vote accepted

Sounds more like a firewall/packet forwarding issue to me... Does your server forward packets at all? How to enable packet forwarding? or more officially UFW (Uncomplicated Firewall).

If packet forwarding is working, does the firewall (and VPN configuration) allow traffic between the clients (I know that there is a config setting called "client-to-client" for this in OpenVPN).

Or maybe openvpn works but client is only able to ping the server helps?


UPDATE Sorry, I just realised: your routing is awry...

6.6.6.0         6.6.6.35        255.255.255.0   UG    0      0        0 tun1
6.6.6.0         6.6.6.29        255.255.255.0   UG    0      0        0 tun0

does not make sense (but should not lead to the problem you describe either).

You are telling your server that network 6.6.6.0/24 is behind both, 6.6.6.29 and 6.6.6.35. That's not good. What are you trying to achieve with these routes? I think you don't need them.

But the server should still be able to route to 6.6.6.29 and .39 respectively. Can you ping 6.6.6.29 and .39 from your server (6.6.6.6)?

By the way: 6.6.6.0/24 is not a network you can use as you like. It would be more appropriate to use a RFC1918 network (10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16).

share|improve this answer
    
Hi! Thank you for your response!! When I do as root # cat /proc/sys/net/ipv4/ip_forward I get 1. When I do as root # ufw I get -bash: ufw: command not found. Any other clue? –  Ricardo Bou Apr 11 '13 at 17:09
    
Updated answer with more thoughts (see UPDATE)... –  scherand Apr 14 '13 at 15:18
    
Hi scherand, thank you again. ping from server to clients work. If I route del 6.6.6.29, then ping from server to client 29 stop working. –  Ricardo Bou Apr 14 '13 at 19:41
    
I did not mean to remove the route for 6.6.6.29 or .35 but the ones for the 6.6.6.0/24 network. So rather do something like route del -net 6.6.6.0/24 gw 6.6.6.29 (and .35) instead of route del 6.6.6.29 (not 100% sure about the syntax). Can you tcpdump on your server? If so, what is the output of the the following two commands when you run them while you try to ping from .29 to .35? tcpdump -n -vvv -i tun0 and tcpdump -n -vvv -i tun1. You should at least get output in the window with the "tun0 command". –  scherand Apr 15 '13 at 19:11
    
If I do tcpdump -n -vvv -i tun0, and I ping 6.6.6.35 from 6.6.6.29 I get: tcpdump: listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes 00:17:16.876853 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 6.6.6.29 > 6.6.6.35: ICMP echo request, id 4664, seq 1, length 64 –  Ricardo Bou Apr 15 '13 at 22:23

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.