tinc - Mar 2016 - AW: issue with tinc and libvirt / Network is already in use by interface tun0

>> 
>> Nice hint, but it's not this simple. Libvirt complains about the 
>> network not the interface. The interfaces have different names already.
>> It seems like tinc bind the subnet on startup and libvirt doesn't 
>> like it
> Well, if it's about the subnet, then it's up to you to change the 
> Subnets in the host config files (and change the tinc-up script
accordingly if necessary), or somehow convince libvirt to use a different
range of IP addresses for its bridge interface.

Sorry, I don't get it. I thought the Subnet parameter is indented for
routing local nets to the remote host.
This way a remote host can access the provided  local nets.

What I have is my host A with vms (ips within 192.168.1.0/24).
My host A has a bridge to the  vm's network. The bridge has the IP
192.168.1.1. Furthor more my host A has a tinc device tun0 with the IP
192.168.2.10.

 My host A has A static internet IP.

I want to connect Host B to Host A via tinc. Host B should be able to access
all VM's within the network  192.168.1.0/24. To get this to work I have to
create on both hosts a hostfile with the name A.conf containing the entries:

Address = XXX.XXX.XXX.XXX
Subnet = 192.168.1.0/24
Subnet = 192.168.2.10/32

right? Or am I wrong?

When I use this entries it works. But only as long as I start libvirt before
tinc.
When I start tinc before libvirt  then I get this error message " Network
is
already in use by interface tuno"

When I remove the entry

Subnet = 192.168.1.0/24

I can't reach the vm's from host B even when I set a route by hand.
It seems like tinc passes only packets on for networks which are listed as
provided networks.

On Sat, 5 Mar 2016, shad0wrunner at gmx.de wrote:
> Sorry, I don't get it. I thought the Subnet parameter is indented for
> routing local nets to the remote host.
> This way a remote host can access the provided  local nets.
> 
> What I have is my host A with vms (ips within 192.168.1.0/24).
> My host A has a bridge to the  vm's network. The bridge has the IP
> 192.168.1.1. Furthor more my host A has a tinc device tun0 with the IP
> 192.168.2.10.
> 
>  My host A has A static internet IP.
> 
> I want to connect Host B to Host A via tinc. Host B should be able to
access
> all VM's within the network  192.168.1.0/24. To get this to work I have
to
> create on both hosts a hostfile with the name A.conf containing the
entries:
> 
> Address = XXX.XXX.XXX.XXX
> Subnet = 192.168.1.0/24
> Subnet = 192.168.2.10/32
> 
> right? Or am I wrong?
This sounds correct - but this only includes what tinc announces to the 
other sides.

But what is in your tinc-up script on host A?

Which IP really gets configured on the tun interface, and which routes 
added? I think here is the problem in your setup.

c'ya
sven-haegar

-- 
Three may keep a secret, if two of them are dead.
- Ben F.

>> Sorry, I don't get it. I thought the Subnet parameter is indented
for
>> routing local nets to the remote host.
>> This way a remote host can access the provided  local nets.
>> 
>> What I have is my host A with vms (ips within 192.168.1.0/24).
>> My host A has a bridge to the  vm's network. The bridge has the IP 
>> 192.168.1.1. Furthor more my host A has a tinc device tun0 with the 
>> IP 192.168.2.10.
>> 
>>  My host A has A static internet IP.
>> 
>> I want to connect Host B to Host A via tinc. Host B should be able to 
>> access all VM's within the network  192.168.1.0/24. To get this to 
>> work I have to create on both hosts a hostfile with the name A.conf
containing the entries:
>> 
>> Address = XXX.XXX.XXX.XXX
>> Subnet = 192.168.1.0/24
>> Subnet = 192.168.2.10/32
>> 
>> right? Or am I wrong?
>This sounds correct - but this only includes what tinc announces to the
other sides.
>But what is in your tinc-up script on host A?
> Which IP really gets configured on the tun interface, and which routes
added? I think here is the problem in your setup.

My up scripts look like this:

tinc-up

ifconfig $INTERFACE 192.168.2.10 netmask 255.255.255.0 iptables -I FORWARD
-i $INTERFACE -j ACCEPT iptables -I FORWARD -o $INTERFACE -j ACCEPT iptables
-I INPUT -i $INTERFACE -j ACCEPT iptables -I INPUT -o $INTERFACE -j ACCEPT

subnet-up

if [ "$NODE" = "A" ]; then
  exit
fi

ip route add $SUBNET dev $INTERFACE


It's strange that depends on the start order of this 2 processes.