Seeking help

[Guus Sliepen]

On Sun, Feb 02, 2014 at 05:38:31PM +0800, Terry T wrote:

> Hi, I am trying to set up a VPN that allows mobile users to access multcast
> information from an information vendor. Hence Tinc is configured as a
> switch.

Tinc can also handle multicast packets in router mode, but then you need some
external daemon to forward multicast packets between the LAN interface and the
VPN.

But also note that tinc treats multicast packets as broadcast packets, so if
only one node on a VPN requests a certain multicast stream, all will receive
it.

> Internet --[ router1 ]------[eth0    VPN   eth1]--------------[ router2
> ]--------- mobile users
> 
> VPN server is running Ubuntu 10.04 and is also configured as a dhcp server
> that hands out IP address to connecting mobile users.
> 
> A bridge (br0) is statically set up at boot through the interfaces script.
> Its bridge port is eth0. br0 is assigned 10.10.145.254 in the
> 10.10.145.0/24network.
> 
> eth1 is 192.168.1.254, gateway is router2 192.168.1.1. Router2 is
> configured to forward both 7142 tcp and udp traffic to 192.168.1.254.
> 
> dhcp3-server is configured to listen on the br0 interface.
> 
> The idea is to allow incoming mobile user join the network and be part of
> the internal network able to receive multicast on the 10.10.145.0/24network.

That should work.

> tinc setup on the VPN server is as follows (/etc/tinc/vpn).
[...]

Your configuration looks correct.

> With the above configuration files, I am not able to receive a valid IP
> address from the server when the Windows client attempts to connect.
> 
> Wireshark on the Windows client sees the following sequence of dialog
> 
> src 0.0.0.0 dst 255.255.255.255 proto dhcp len 342 Info DHCP Discover -
> transaction id 0xd70a60a8
>                       broadcast           proto arp   len 42   Info Who has
> 10.10.145.105? Tell 10.10.145.254
> src 10.10.145.254 dst 10.10.145.105 proto dhcp len 347 Info DHCP Offer -
> transaction id 0xd70a60a8
> src 0.0.0.0 dst 255.255.255.255 proto dhcp len 347 Info DHCP Request -
> transaction id 0xd70a60a8
>                       broadcast           proto arp   len 42   Info Who has
> 10.10.145.105? Tell 10.10.145.254
> src 0.0.0.0 dst 255.255.255.255 proto dhcp len 347 Info DHCP Request -
> transaction id 0xd70a60a8
> src 0.0.0.0 dst 255.255.255.255 proto dhcp len 347 Info DHCP Request -
> transaction id 0xd70a60a8
> 
> And on the Linux server, using tcpdump -i br0 -vvv -s 1500 '((port 67 or
> port 68) and (udp[8:1] = 0x1))'
> 
> The only conversation captured is the
> 
> 0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, request
> from 00:ff:0c:02:c3:f0 (oui unknown), length 300, xid 0x856c7d18, flags
> [none] (0x0000)
> :
> DHCP-Message Option 53, length 1: Discover

Well, since you are only capturing DHCP Discovery messages, that is the only
thing you will see. The dump from the Windows client shows that it received an
Offer from the DHCP server. You should drop the "and (udp[8:1] = 0x1)" from the
filter and try again.

If the DHCP Request packets still don't show up on the Linux side, start tincd
with the options "-d5 -D" on both sides. This will cause it to run in the
foreground and print a lot of debugging information, and might contain hints
about what is going wrong.

If you do see the request packets, check whether you have firewall rules on
either the Linux server or Windows client that might be blocking those packets.
And check the logs from the DHCP server.

-- 
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/20140203/5c7812d0/attachment.sig>