tinc - Oct 2016 - Can't Route LAN Traffic Behind Tinc Network

Thanks again Keith.  I disabled UFW and flushed iptables completely, but same
result.  Pings from the external node are reaching the internal node on the
tinc0 interface but nothing happens after that.  Now that I'm thinking of
it, I did some masquerading in order to get OpenVPN to work on another box, I
wonder if that would be applicable here?



Very Respectfully,

Kismet Agbasi

-----Original Message-----
From: Keith [mailto:keith at rhizomatica.org] 
Sent: Thursday, October 6, 2016 10:47 AM
To: kagbasi at centraltruck.net; tinc at tinc-vpn.org
Subject: Re: Can't Route LAN Traffic Behind Tinc Network



On 06/10/2016 16:33, Kismet Agbasi wrote:
> Thanks Keith.  Here's the output:
OK. I'd like to say that I recognize this is now off topic for the tinc
list, as it really is about basic routing and firewalls and has little if
anything to do with tinc at this point. However, it's a low volume list, so
unless anyone complains, lets thrash it out here.

> wrong interface......hmmm.  As you can tell I use UFW so here's the
output of "ufw status numbered":
>
>      root at ubuntu2:~# ufw status numbered
>      Status: active
I'm actually unfamiliar with ufw, as I am with most of the plethora of
iptables-helpers out there.
I could ask you to post a list of all tools and chain, (iptables -vnL) but can
we just do something simple first as a test?

Can you disable your ufw and then run iptables -F FORWARD (just to be
sure) and then test your tinc<->LAN connectivity?
your default FORWARD POLICY is ACCEPT so this quick check should let us know if
the firewall rules are getting in the way.

I guess you should quicky re-enable your ufw rules then, so as not to remain
unprotected. You have a public IP on this box, I understand.
K/

On 06/10/2016 17:16, Kismet Agbasi wrote:
> Thanks again Keith.  I disabled UFW and flushed iptables completely, but
same result.  Pings from the external node are reaching the internal node on the
tinc0 interface but nothing happens after that.  Now that I'm thinking of
it, I did some masquerading in order to get OpenVPN to work on another box, I
wonder if that would be applicable here?
Weird. I dunno. something is missing from the picture.
You could check if the pings to 172.23.6.x are going out on the eth1
interface with
tcpdump -i eth1 icmp
You are trying to ping this internal windows box via tinc, right? (the
one from where you posted a ping to 172.23.6.149?)
Does it have windows firewall enabled? Sometimes windows firewall blocks
incoming pings.

can you ping it from the machine called ubuntu2?

k/

Oh yes - so ubuntu2 is the linux host running tinc on my LAN (the one I'm
referring to as INSIDE node).  I can ping it from my Windows machine and vice
versa without any trouble.  I can also ping all other devices on my LAN from
ubuntu2 and  vice versa, also without any issues.  Output of "tcpdump -I
eth1 icmp" confirms that packets are reaching the box and going out on the
correct interface.  10.9.0.4 is the tinc IP address of EXTERNAL node.

     root at ubuntu2:~# tcpdump -i eth1 icmp
     tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
     listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
     12:12:44.625280 IP 10.9.0.4 > 172.23.6.1: ICMP echo request, id 16606,
seq 1, length 64
     12:12:45.630867 IP 10.9.0.4 > 172.23.6.1: ICMP echo request, id 16606,
seq 2, length 64
     12:12:46.638898 IP 10.9.0.4 > 172.23.6.1: ICMP echo request, id 16606,
seq 3, length 64
     12:12:47.646764 IP 10.9.0.4 > 172.23.6.1: ICMP echo request, id 16606,
seq 4, length 64
     12:12:48.654765 IP 10.9.0.4 > 172.23.6.1: ICMP echo request, id 16606,
seq 5, length 64
     12:12:49.662973 IP 10.9.0.4 > 172.23.6.1: ICMP echo request, id 16606,
seq 6, length 64
     12:12:50.670642 IP 10.9.0.4 > 172.23.6.1: ICMP echo request, id 16606,
seq 7, length 64
     12:12:51.678942 IP 10.9.0.4 > 172.23.6.1: ICMP echo request, id 16606,
seq 8, length 64
     12:12:52.686627 IP 10.9.0.4 > 172.23.6.1: ICMP echo request, id 16606,
seq 9, length 64
     12:12:53.694864 IP 10.9.0.4 > 172.23.6.1: ICMP echo request, id 16606,
seq 10, length 64
     12:12:54.702841 IP 10.9.0.4 > 172.23.6.1: ICMP echo request, id 16606,
seq 11, length 64
     12:12:55.710574 IP 10.9.0.4 > 172.23.6.1: ICMP echo request, id 16606,
seq 12, length 64
     12:12:56.718886 IP 10.9.0.4 > 172.23.6.1: ICMP echo request, id 16606,
seq 13, length 64
     12:12:57.726749 IP 10.9.0.4 > 172.23.6.1: ICMP echo request, id 16606,
seq 14, length 64
     12:12:58.734801 IP 10.9.0.4 > 172.23.6.1: ICMP echo request, id 16606,
seq 15, length 64
     ^C
     15 packets captured
     16 packets received by filter
     0 packets dropped by kernel




-----Original Message-----
From: Keith [mailto:keith at rhizomatica.org] 
Sent: Thursday, October 6, 2016 11:27 AM
To: kagbasi at centraltruck.net; tinc at tinc-vpn.org
Subject: Re: Can't Route LAN Traffic Behind Tinc Network



On 06/10/2016 17:16, Kismet Agbasi wrote:
> Thanks again Keith.  I disabled UFW and flushed iptables completely, but
same result.  Pings from the external node are reaching the internal node on the
tinc0 interface but nothing happens after that.  Now that I'm thinking of
it, I did some masquerading in order to get OpenVPN to work on another box, I
wonder if that would be applicable here?
Weird. I dunno. something is missing from the picture.
You could check if the pings to 172.23.6.x are going out on the eth1 interface
with tcpdump -i eth1 icmp You are trying to ping this internal windows box via
tinc, right? (the one from where you posted a ping to 172.23.6.149?) Does it
have windows firewall enabled? Sometimes windows firewall blocks incoming pings.

can you ping it from the machine called ubuntu2?

k/