Le mar. 15 janv. 2019 à 03:13, Lars Kruse <lists at sumpfralle.de> a écrit
:
> Hello Julien,
>
>
> Am Mon, 14 Jan 2019 22:15:47 +0100
> schrieb Julien dupont <marcelvierzon at gmail.com>:
>
>
> > ** Test 1 **
> > On VPN_office I use 'tcpdump -npi any icmp and host
192.168.1.3'
> > When pinging 192.168.1.1 from client 1, with no success, I see no
packet
> > passing.
>
> Sorry - the tcpdump command should end with "192.168.1.1" instead
of
> "192.168.1.3".
> (everything following "any" is a filter for the interesting
traffic)
>
>
Yes obviously.
In that case I see:
IP 172.16.0.3 > 192.168.1.1: ICMP echo request, id2135, seq1, length 64
IP 172.16.0.3 > 192.168.1.1: ICMP echo request, id2135, seq2, length 64
IP 172.16.0.3 > 192.168.1.1: ICMP echo request, id2135, seq3, length 64
Packet goes through but no PONG back if I understand correctly. That's
probably where it goes wrong.
>
> > When pinging 192.168.1.3 from client 1, with success, I see packet
> passing:
> > IP 172.16.0.3 > 192.168.1.3: ICMP echo request, id 2648, seq 23,
length
> 64
> > IP 192.168.1.3 > 172.16.0.3: ICMP echo request, id 2648, seq 23,
length
> 64
> > ...
>
> OK. As you said, this works.
>
>
> > ** Test 2 *
> > I use a machine from the office LAN with IP 192.168.1.100 to ping
> > VPN_office (172.16.0.2), VPN_out (172.16.0.1) and VPN_client
> (172.16.0.3) -
> > I can't access the router right now. They all work. Here is the
output of
> > VPN_client:
> > > ping 172.16.0.3
> > PING 172.16.0.3 (172.16.0.3) 56(84) bytes of data.
> > From 192.168.1.1 icmp_seq=2 Redirect Host (New nexthop: 192.168.1.3)
> > From 192.168.1.1: icmp_seq=2 Redirect Host (New nexthop: 192.168.1.3)
> > ...
> >
> > This is the result of the traffic redirection rule I put in the
router.
>
> OK. So the route is properly configured on your router.
>
> Now you should check whether such a ping results in the expected traffic.
> E.g. you could execute "tcpdump -npi any icmp" on 192.168.1.3.
Here you
> should
> see incoming packets from 192.168.1.100 and (a few milliseconds later)
> forwarded
> packets towards the VPN. If this works, then you could check, whether the
> forwarded traffic really goes into the tinc VPN
> (e.g. "tcpdump -npi YOUR_TINC_INTERFACE icmp").
> If everything goes well, then you can check, whether your tinc node on the
> other side also sees the expected traffic (using tcpdump on "any"
interface
> again): incoming as well as forwarded. Play around with the selected
> network
> interface for tcpdump on different hosts until you understand, where your
> packets get lost.
>
>
On VPN_office 'tcdump -npi any icmp', on 192.168.1.100 'ping
172.16.0.3':
192.168.1.100 > 172.16.0.3: ICMP echo request, id 11452, seq1, length 64
192.168.1.100 > 172.16.0.3: ICMP echo request, id 11452, seq2, length 64
192.168.1.100 > 172.16.0.3: ICMP echo request, id 11452, seq3, length 64
...
Does that mean there is no PONG back?
On VPN_office 'tcdump -npi any icmp', on 192.168.1.100 'ping
172.16.0.2'
(VPN_office):
192.168.1.100 > 172.16.0.2: ICMP echo request, id 40111, seq1, length 64
172.16.0.2 > 192.168.1.100: ICMP echo reply, id 40111, seq1, length 64
> Happy packet hunting!
>
> Cheers,
> Lars
>
> PS: currently you are using the two of the most popular private IP ranges
> (172.16.0.0/24 and 192.168.1.0/24) for your two networks. This will
> inevitably
> cause problems as soon as people want to work within these networks from
> home
> (e.g. via a VPN). Maybe this is the right time to change these subnets into
> something less widely used?
> _______________________________________________
> 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/20190115/cb403681/attachment-0001.html>