Hi Lars
Thank you for reply.
My apologies it is running in "*TAP*" mode.
root at 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 at tinc-srv02:~# cat /proc/sys/net/bridge/bridge-nf-call-iptables
1
root at tinc-srv02:~# cat /proc/sys/net/ipv4/ip_forward
1
root at tinc-srv02:~#
I dont have ebtables installed , do I need it installed in order to handle
the ARP requests/replies?
root at tinc-srv02:~# ebtables -L
The program 'ebtables' is currently not installed. You can install it by
typing:
apt-get install ebtables
root at 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 at 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
<yazeedfataar at hotmail.com>
On Sun, Apr 10, 2016 at 3:54 PM, Lars Kruse <lists at sumpfralle.de>
wrote:
> Hello Yazeed,
>
>
> Am Tue, 5 Apr 2016 11:26:55 +0300
> schrieb Yazeed Fataar <yazeedfataar at gmail.com>:
>
> > [..]
> >
> > *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
> tinc at tinc-vpn.org
> https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.tinc-vpn.org/pipermail/tinc/attachments/20160410/27581781/attachment.html>