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.
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.
tinc setup on the VPN server is as follows (/etc/tinc/vpn).
/etc/tinc/vpn/tinc.conf
mode = switch
name = server
addressfamily = ipv4
privatekeyfile = /etc/tinc/vpn/rsa_key.priv
/etc/tinc/vpn/tinc-up
ifconfig $INTERFACE 0.0.0.0 up promisc
brctl addif br0 $INTERFACE
/etc/tinc/vpn/hosts/server
compression = 9
address = <public IP of this server>
Cipher = none
Digest = none
Port = 7142
-----BEGIN RSA PUBLIC KEY-----
:::
-----END RSA PUBLIC KEY-----
Soon as tinc started, a 'vpn' interfaced to added to br0. eth0 and br0
have
identical MAC address.
brctl show shows eth0 and vpn
Client is a Windows XP client
c:\program files\tinc\vpn\tinc.conf
ConnectTo=server
Mode=switch
Name=vpnclient
AddressFamily=ipv4
PrivateKeyFile=c:\progra~1\tinc\vpn\rsa_key.priv
Interface=Win-Tap
c:\program files\tinc\vpn\vpnclient
subnet=10.10.145.0/24
compression=9
cipher=none
digest=none
-----BEGIN RSA PUBLIC KEY-----
:::
-----END RSA PUBLIC KEY-----
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
:
:
I don't know where the problem lies. It seems that after the initial DHCP
Discover is received by the server, all subsequent messages from the client
are not received. On the Windows side, it has received the DHCP Offer and
attempted to reply with the DHCP Request which seems lost. After repeated
attempt to request the offered IP, Win-tap gives up and self-assign a 169
address.
If I assign Win-Tap a valid IP, neither side could ping each other.
Please suggest what I should do to make this vpn work.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.tinc-vpn.org/pipermail/tinc/attachments/20140202/d786cfbe/attachment.html>
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: DiscoverWell, 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>