How to enable debug in glorytun

[felartu]

Hi,

Is there a way to show debug information on Glorytun?

We have a fresh install setup between a local VM and an EC2 instance in AWS where we see random packet drop with just PING going between the two.

Client side:

[root@localhost tunnel]# ping 10.0.1.1
PING 10.0.1.1 (10.0.1.1) 56(84) bytes of data.
64 bytes from 10.0.1.1: icmp_seq=1 ttl=64 time=66.0 ms
64 bytes from 10.0.1.1: icmp_seq=3 ttl=64 time=91.4 ms
64 bytes from 10.0.1.1: icmp_seq=4 ttl=64 time=65.8 ms
64 bytes from 10.0.1.1: icmp_seq=5 ttl=64 time=78.4 ms
64 bytes from 10.0.1.1: icmp_seq=6 ttl=64 time=76.8 ms
64 bytes from 10.0.1.1: icmp_seq=8 ttl=64 time=88.0 ms
64 bytes from 10.0.1.1: icmp_seq=9 ttl=64 time=66.4 ms
64 bytes from 10.0.1.1: icmp_seq=10 ttl=64 time=70.0 ms
64 bytes from 10.0.1.1: icmp_seq=11 ttl=64 time=127 ms
64 bytes from 10.0.1.1: icmp_seq=12 ttl=64 time=67.1 ms
^C
--- 10.0.1.1 ping statistics ---
12 packets transmitted, 10 received, 16% packet loss, time 11017ms

Server side:

13:41:26.135992 IP 10.0.1.2 > 10.0.1.1: ICMP echo request, id 20256, seq 1, length 64
13:41:26.136007 IP 10.0.1.1 > 10.0.1.2: ICMP echo reply, id 20256, seq 1, length 64
13:41:28.164192 IP 10.0.1.2 > 10.0.1.1: ICMP echo request, id 20256, seq 3, length 64
13:41:28.164206 IP 10.0.1.1 > 10.0.1.2: ICMP echo reply, id 20256, seq 3, length 64
13:41:29.141201 IP 10.0.1.2 > 10.0.1.1: ICMP echo request, id 20256, seq 4, length 64
13:41:29.141219 IP 10.0.1.1 > 10.0.1.2: ICMP echo reply, id 20256, seq 4, length 64
13:41:30.155279 IP 10.0.1.2 > 10.0.1.1: ICMP echo request, id 20256, seq 5, length 64
13:41:30.155292 IP 10.0.1.1 > 10.0.1.2: ICMP echo reply, id 20256, seq 5, length 64
13:41:31.155671 IP 10.0.1.2 > 10.0.1.1: ICMP echo request, id 20256, seq 6, length 64
13:41:31.155686 IP 10.0.1.1 > 10.0.1.2: ICMP echo reply, id 20256, seq 6, length 64
13:41:33.169043 IP 10.0.1.2 > 10.0.1.1: ICMP echo request, id 20256, seq 8, length 64
13:41:33.169055 IP 10.0.1.1 > 10.0.1.2: ICMP echo reply, id 20256, seq 8, length 64
13:41:34.149270 IP 10.0.1.2 > 10.0.1.1: ICMP echo request, id 20256, seq 9, length 64
13:41:34.149289 IP 10.0.1.1 > 10.0.1.2: ICMP echo reply, id 20256, seq 9, length 64
13:41:35.154276 IP 10.0.1.2 > 10.0.1.1: ICMP echo request, id 20256, seq 10, length 64
13:41:35.154289 IP 10.0.1.1 > 10.0.1.2: ICMP echo reply, id 20256, seq 10, length 64
13:41:36.213337 IP 10.0.1.2 > 10.0.1.1: ICMP echo request, id 20256, seq 11, length 64
13:41:36.213360 IP 10.0.1.1 > 10.0.1.2: ICMP echo reply, id 20256, seq 11, length 64
13:41:37.155690 IP 10.0.1.2 > 10.0.1.1: ICMP echo request, id 20256, seq 12, length 64
13:41:37.155705 IP 10.0.1.1 > 10.0.1.2: ICMP echo reply, id 20256, seq 12, length 64

Sometimes the client sends everything, the server replies, we see the encrypted reply with tcpdump but glorytun fails to decrypt it:

client side:

[root@localhost tunnel]# ping 10.0.1.1
PING 10.0.1.1 (10.0.1.1) 56(84) bytes of data.
64 bytes from 10.0.1.1: icmp_seq=18 ttl=64 time=71.0 ms
^C
--- 10.0.1.1 ping statistics ---
70 packets transmitted, 1 received, 98% packet loss, time 69010ms
rtt min/avg/max/mdev = 71.074/71.074/71.074/0.000 ms

server side:

<truncated>
13:38:44.948533 IP 10.0.1.1 > 10.0.1.2: ICMP echo reply, id 20223, seq 65, length 64
13:38:45.924772 IP 10.0.1.2 > 10.0.1.1: ICMP echo request, id 20223, seq 66, length 64
13:38:45.924787 IP 10.0.1.1 > 10.0.1.2: ICMP echo reply, id 20223, seq 66, length 64
13:38:46.927813 IP 10.0.1.2 > 10.0.1.1: ICMP echo request, id 20223, seq 67, length 64
13:38:46.927826 IP 10.0.1.1 > 10.0.1.2: ICMP echo reply, id 20223, seq 67, length 64
13:38:47.924402 IP 10.0.1.2 > 10.0.1.1: ICMP echo request, id 20223, seq 68, length 64
13:38:47.924416 IP 10.0.1.1 > 10.0.1.2: ICMP echo reply, id 20223, seq 68, length 64
13:38:48.930502 IP 10.0.1.2 > 10.0.1.1: ICMP echo request, id 20223, seq 69, length 64
13:38:48.930515 IP 10.0.1.1 > 10.0.1.2: ICMP echo reply, id 20223, seq 69, length 64
13:38:49.925581 IP 10.0.1.2 > 10.0.1.1: ICMP echo request, id 20223, seq 70, length 64
13:38:49.925595 IP 10.0.1.1 > 10.0.1.2: ICMP echo reply, id 20223, seq 70, length 64

[angt]

Hi,
Not really, tcpdump is your best friend here :)
And quiet often the problem is not really in the tunnel itself.
What version do you use and how did you setup your path ?
Also, do you use a specific qdisc on the tun device ?

[angt]

I have started something about monitoring time desynchronization and bad decryption.
But it's not yet available from the command line.

[angt]

As a first draft, to help diagnostics, I just added option bad to the command glorytun show.
This will show you errors about bad encryption, key exchange and time desync.

[felartu]

no qdisc, just regular point to point tunnel.

Do we require NTP to be running for sync? What is the time tolerance for glorytun in the case of desync?

[angt]

Yes, time synchronization is required to prevent replay attacks.
By default the option timetolerance is set to 10min.

[angt]

0.2.2 is out and you can check errors with the command glorytun show bad.

[jedisct1]

[angt]

glorytun show errors was soooo boring (!! ◠‿◠)