tinc - Feb 2014 - larger than minimun MTU, forwarding via other node

First off, I would like to express my appreciation for the tinc software,
it has been such a great vpn solution for what i need, its amazing.

I am setting up another node on the vpn. "KVM" is my public facing
node,
"MacbookAir" is my workstation, "NewNode" is my node i have
recently
configured and the one with the issue presumably. NewNode and MacbookAir
are on the same network, KVM is on a separate physical network.

I configure NewNode per usual, and then when i ping from MacbookAir to
NewNode over the vpn network, i get very slow speeds, but when i ping
NewNode over my local network, i get reasonable speeds. From my
understanding, tinc will forward packets through any available node until
it can establish a direct p2p or node-to-node connection, is this correct?
This does not seem to happen.

user at MacbookAir:~$ # local network
user at MacbookAir:~$ ping 10.0.0.10
PING 10.0.0.10 (10.0.0.10) 56(84) bytes of data.
64 bytes from 10.0.0.10: icmp_seq=1 ttl=64 time=8.36 ms
64 bytes from 10.0.0.10: icmp_seq=2 ttl=64 time=1.18 ms
64 bytes from 10.0.0.10: icmp_seq=3 ttl=64 time=1.15 ms
64 bytes from 10.0.0.10: icmp_seq=4 ttl=64 time=2.88 ms
^C
--- 10.0.0.10 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 1.152/3.396/8.363/2.952 ms
user at MacbookAir:~$ # vpn network
user at MacbookAir:~$ ping 192.168.123.100
PING 192.168.123.100 (192.168.123.100) 56(84) bytes of data.
64 bytes from 192.168.123.100: icmp_seq=1 ttl=64 time=94.4 ms
64 bytes from 192.168.123.100: icmp_seq=2 ttl=64 time=95.5 ms
64 bytes from 192.168.123.100: icmp_seq=3 ttl=64 time=94.0 ms
64 bytes from 192.168.123.100: icmp_seq=4 ttl=64 time=95.3 ms
^C
--- 192.168.123.100 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 94.009/94.857/95.587/0.744 ms



i did not like the slow pings and MacbookAir did not seem to make a direct
vpn connection with NewNode, so i ran "sudo tincd -n vpn -D -d5" and
got
the messages below.

Packet for MacbookAir (12.34.56.78 port 27091) larger than minimum MTU,
forwarding via KVM
Sending packet of 98 bytes to KVM (87.65.43.21 port 657)
Received packet of 98 bytes from KVM (87.65.43.21 port 657)
Writing packet of 98 bytes to Linux tun/tap device (tap mode)
Read packet of 98 bytes from Linux tun/tap device (tap mode)
Sending packet of 98 bytes to MacbookAir (12.34.56.78 port 27091)
Packet for MacbookAir (12.34.56.78 port 27091) larger than minimum MTU,
forwarding via KVM


I see that KVM is doing the forwarding rather than the two nodes making a
direct connection. How do fix this issue? I am almost certain that I didnt
configure something correctly, but i do not know where to start
troubleshooting and I am hoping that someone would have some tips for me.
Anyone know how to fix this?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.tinc-vpn.org/pipermail/tinc/attachments/20140131/4e836c87/attachment.html>

On Fri, Jan 31, 2014 at 07:39:21PM -0800, Cobin Bluth wrote:
> First off, I would like to express my appreciation for the tinc software,
> it has been such a great vpn solution for what i need, its amazing.
Thanks!
> I am setting up another node on the vpn. "KVM" is my public
facing node,
> "MacbookAir" is my workstation, "NewNode" is my node i
have recently
> configured and the one with the issue presumably. NewNode and MacbookAir
> are on the same network, KVM is on a separate physical network.
> 
> I configure NewNode per usual, and then when i ping from MacbookAir to
> NewNode over the vpn network, i get very slow speeds, but when i ping
> NewNode over my local network, i get reasonable speeds. From my
> understanding, tinc will forward packets through any available node until
> it can establish a direct p2p or node-to-node connection, is this correct?
> This does not seem to happen.
Yes, however I think the problem in your situation is that NewNode and
MacbookAir learn each other's IP address from KVM, and since they are behind
a
NAT, KVM only knows the IP address of the NAT device. Therefore, NewNode and
MacbookAir try to communicate to each other via the NAT device (this is called
hairpin routing). Your NAT doesn't support this, so NewNode and MacbookAir
think they cannot connect directly to each other.

The fix is to add "LocalDiscovery = yes" to either MacbookAir or
Newnode's
tinc.conf. This will cause them to send broadcast packets on the local network,
so they can learn each other's local IP address.

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus at tinc-vpn.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL:
<http://www.tinc-vpn.org/pipermail/tinc/attachments/20140201/8772a676/attachment.sig>