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

>> 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.

Hello Dieter,

could it be that your tinc node adds the route 192.168.1.0/24 and that libvirt
later fails when it tries to configure the local bridge and add the same route?
You could verify this by adding some output (writing a log file?) to the
subnet-up script.

If this should be the case then you need to find out, why tinc calls the
subnet-up script for its own local subnets. Maybe there are some mixed up subnet
definitions in the hosts files?

Lars

Hello Lars,

you made my day :)
You'r right.Thanks! My script did add a route for 192.168.1.0/24 (it's a
bug/typo in my script).

I could reproduce the error by stoping the libvirt network, add the route
and start
the libvirt network. Then I get the error message "Network is already in
use
by interface tun0"

I have to say the error message could point out that a route already exists
but any way.
Now it is up and running.

Regards 
dieter

-----Urspr?ngliche Nachricht-----
Von: tinc [mailto:tinc-bounces at tinc-vpn.org] Im Auftrag von Lars Kruse
Gesendet: Samstag, 5. M?rz 2016 16:33
An: tinc at tinc-vpn.org
Betreff: Re: issue with tinc and libvirt / Network is already in use by
interface tun0

Hello Dieter,

could it be that your tinc node adds the route 192.168.1.0/24 and that
libvirt later fails when it tries to configure the local bridge and add the
same route?
You could verify this by adding some output (writing a log file?) to the
subnet-up script.

If this should be the case then you need to find out, why tinc calls the
subnet-up script for its own local subnets. Maybe there are some mixed up
subnet definitions in the hosts files?

Lars
_______________________________________________
tinc mailing list
tinc at tinc-vpn.org
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

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.
> 
> 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.
Could there be another node (B/C/D?) that includes a "Subnet = 
192.168.1.0/24" statement?

Add something like the following to you subnet-up:

logger -t "tinc.$NETNAME.subnet-up" -p daemon.info "subnet-up
from
$NODE for $SUBNET ($REMOTEADDRESS:$REMOTEPORT)"

(one line)

Add it after the $NODE="A" check.

c'ya
sven-haegar

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