Hi Lars Thank you for reply.
My apologies it is running in "*TAP*" mode. root@tinc-srv:~# tincd -n netname -D -d3 tincd 1.0.23 (Dec 5 2013 17:16:47) starting, debug level 3 /dev/net/tun is a Linux tun/tap device (tap mode) I have enabled ip forwarding and it seems that bridging rules is enabled root@tinc-srv02:~# cat /proc/sys/net/bridge/bridge-nf-call-iptables 1 root@tinc-srv02:~# cat /proc/sys/net/ipv4/ip_forward 1 root@tinc-srv02:~# I dont have ebtables installed , do I need it installed in order to handle the ARP requests/replies? root@tinc-srv02:~# ebtables -L The program 'ebtables' is currently not installed. You can install it by typing: apt-get install ebtables root@tinc-srv02:~# This is tcpdump i have issued on tinc-srv02 (Site 2). It receives the ARP request and sends it to the Server in Site to , but not getting ARP response. Is this perhaps a VMware vswitch issue related to ARP queries being dropped between VM's . I have no access to the esxi host only to the vm's. TCPDUMP root@tinc-srv02:~# tcpdump -i bridge | grep 10.32.0.22 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on bridge, link-type EN10MB (Ethernet), capture size 65535 bytes 15:15:17.344008 ARP, Request who-has 10.32.0.11 tell 10.32.0.22, length 46 15:15:18.286495 IP 10.32.0.12* (Site 1 Server)* > 10.32.0.22* (Site 2 Server)*: ICMP echo request, id 1, seq 14, length 80 15:15:18.341668 ARP, Request who-has 10.32.0.11 tell 10.32.0.22, length 46 15:15:19.339975 ARP, Request who-has 10.32.0.11 tell 10.32.0.22, length 46 15:15:20.288630 IP 10.32.0.12 > 10.32.0.22: ICMP echo request, id 1, seq 15, length 80 15:15:20.338987 ARP, Request who-has 10.32.0.11 tell 10.32.0.22, length 46 15:15:21.336696 ARP, Request who-has 10.32.0.11 tell 10.32.0.22, length 46 15:15:22.289760 IP 10.32.0.12 > 10.32.0.22: ICMP echo request, id 1, seq 16, length 80 15:15:22.335111 ARP, Request who-has 10.32.0.11 tell 10.32.0.22, length 46 15:15:23.334344 ARP, Request who-has 10.32.0.11 tell 10.32.0.22, length 46 15:15:24.291681 IP 10.32.0.12 > 10.32.0.22: ICMP echo request, id 1, seq 17, length 80 15:15:24.331904 ARP, Request who-has 10.32.0.11 tell 10.32.0.22, length 46 15:15:25.330255 ARP, Request who-has 10.32.0.11 tell 10.32.0.22, length 46 15:15:26.293099 IP 10.32.0.12 > 10.32.0.22: ICMP echo request, id 1, seq 18, length 80 15:15:26.329447 ARP, Request who-has 10.32.0.11 tell 10.32.0.22, length 46 15:15:27.342722 ARP, Request who-has 10.32.0.11 tell 10.32.0.22, length 46 15:15:28.295339 IP 10.32.0.12 > 10.32.0.22: ICMP echo request, id 1, seq 19, length 80 15:15:28.341110 ARP, Request who-has 10.32.0.11 tell 10.32.0.22, length 46 15:15:29.339932 ARP, Request who-has 10.32.0.11 tell 10.32.0.22, length 46 15:15:30.296755 IP 10.32.0.12 > 10.32.0.22: ICMP echo request, id 1, seq 20, length 80 15:15:30.337919 ARP, Request who-has 10.32.0.11 tell 10.32.0.22, length 46 15:15:31.336231 ARP, Request who-has 10.32.0.11 tell 10.32.0.22, length 46 15:15:32.296068 IP 10.32.0.12 > 10.32.0.22: ICMP echo request, id 1, seq 21, length 80 15:15:32.335125 ARP, Request who-has 10.32.0.11 tell 10.32.0.22, length 46 15:15:33.332990 ARP, Request who-has 10.32.0.11 tell 10.32.0.22, length 46 15:15:34.297818 IP 10.32.0.12 > 10.32.0.22: ICMP echo request, id 1, seq 22, length 80 15:15:34.331521 ARP, Request who-has 10.32.0.11 tell 10.32.0.22, length 46 15:15:35.330205 ARP, Request who-has 10.32.0.11 tell 10.32.0.22, length 46 15:15:36.299904 IP 10.32.0.12 > 10.32.0.22: ICMP echo request, id 1, seq 23, length 80 15:15:36.328150 ARP, Request who-has 10.32.0.11 tell 10.32.0.22, length 46 15:15:37.342065 ARP, Request who-has 10.32.0.11 tell 10.32.0.22, length 46 15:15:38.331289 IP 10.32.0.12 > 10.32.0.22: ICMP echo request, id 1, seq 24, length 80 15:15:38.341090 ARP, Request who-has 10.32.0.11 tell 10.32.0.22, length 46 15:15:39.339068 ARP, Request who-has 10.32.0.11 tell 10.32.0.22, length 46 Regards Yazeed Fataar <[email protected]> On Sun, Apr 10, 2016 at 3:54 PM, Lars Kruse <[email protected]> wrote: > Hello Yazeed, > > > Am Tue, 5 Apr 2016 11:26:55 +0300 > schrieb Yazeed Fataar <[email protected]>: > > > [..] > > > > *Site 1* > > Server -ping- Site 1 (tinc-srv01) - Success > > Server -ping- Site 2 (tinc-srv02) - Success > > Server -ping- Site 2 - Server 2 - Failure > > > > > > *Site 2* > > Server -ping- Site 2 (tinc-srv02) - Success > > Server -ping- Site 1 (tinc-srv01) - Failure > > Server -ping- Site 1 - Server 1 - Failure > > Could it be that ip_forward is disabled on tinc-srv02? Or maybe brige > traffic filtering is active without the required firewall rules? > > /proc/sys/net/ipv4/ip_forward > /proc/sys/net/bridge/bridge-nf-call-iptables > > > > Is there a feature I need to enable ( ie Proxy Arp) on tinc-srv02 the > arp to > > reach the server (site 2) ? > > I am not aware of any unusual network setup requirements for tinc. > > > > My tinc-srv02 in Site 2 has one interface that I have bridged with tun0. > > Are you sure that this works? I understand tun devices to be layer 3 > interfaces > - thus they cannot be connected to a bridge (layer 2), as far as I > understand. > > Cheers, > Lars > _______________________________________________ > tinc mailing list > [email protected] > https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc >
_______________________________________________ tinc mailing list [email protected] https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
