Every other service I use on VPN only uses the interface for the VPN
address that I enter. I don't know why Ekiga would send it out to
every interface. Plus, part of the reason for using Ekiga over VPN is
to have a private conversation, so sending signals out to every
interface makes noise that I don't want. I could live with this for
the time being, so just having a fix for the response of Ekiga for
userB would make me satisfied for now.
The routing is configured correctly, as you can see from my firewall
log examples. It's Ekiga for userB that's trying to communicate with
the LAN address instead of the VPN address.
Does the latest Ekiga do this correctly through VPN? One of the main
reasons I'm using Ubuntu 12.04 is that it's long term support until
2017, so if the latest version of Ekiga cannot get into the Ubuntu
repository, that could be a problem for me. If installing the latest
version from source is a solution, I could live with it.
On 09/29/2013 at 10:04 AM, "Damien Sandras" wrote:
What Ekiga is supposed to do, is to send one message per
interface with the interface IP address as source. If your
routing is well configured, then only one of the various SIP
messages should reach the remote user.
Please note that Ekiga 3.3.2 is an old development release
which is not intended for public use...
Le 29/09/13 10:45, cookedbr...@hushmail.com a écrit :
I want to use Ekiga without a central server by
manually entering IP addresses to connect directly to others.
This works fine on a LAN. But on VPN it doesn't work because
of a bug, and this bug actually exists with the LAN but it's
not noticed. I am using Ekiga version 3.3.2-0ubuntu3 on Ubuntu
12.04.
What happens is that when userA sends a message out to userB,
Ekiga attempts to sends communications out to ALL Internet
interfaces that userA is connected to. I discovered this from
the firewall log. As an example of what's happening in my
situation, say that userA has a LAN address of 192.168.1.1 but
is also on a VPN with a VPN address of 10.8.0.6. When Ekiga is
used to send a direct message to userB who is on the LAN with an
address of 192.168.1.2 (sip:userB@192.168.1.2), Ekiga sends this
signal out from userA on both 192.168.1.2 and 10.8.0.6. So in
the ufw firewall log of userA you will see something like this:
OUT=eth0 SRC=192.168.1.1 DST=192.168.1.2
OUT=eth0 SRC=10.8.0.6 DST=192.168.1.2
Notice that the second one says "eth0" even though it's using
the tun() interface. That's part of the bug. When this is over
the LAN it's not a problem. But when trying to do it over a
VPN it is a problem. So now let's say userB is far away in
another building, but connected to the same VPN as userA.
userB has a VPN address of 10.8.0.10. This time userA sends a
message to userB using the VPN address. userA will enter
"sip:userB@10.8.0.10" into Ekiga. userA can actually send
messages to userB and userB will see them. However, userB cannot
send any messages back to userA. The firewall logs show why this
is. Here is what the firewall log for userA will look like when
sending the message out:
OUT=tun0 SRC=192.168.1.1 DST=10.8.0.10
OUT=tun0 SRC=10.8.0.6 DST=10.8.0.10
Notice that the first one is tun0 but using the LAN as
source. That's part of the bug. But it's able to send messages
over the VPN to userB at 10.8.0.10. But when userB tries to
send messages back, it tries to send them to the LAN address
of userA. Here is what the firewall log will look like for
userB when trying to send communications to userA. userB has a
LAN address of 172.16.0.1 with a VPN address of 10.8.0.10 and
is communicating to userA with "sip:userA@10.8.0.6". Here is
what the firewall log of userB looks like:
OUT=tun0 SRC=172.16.0.1 DST=192.168.1.1
OUT=tun0 SRC=10.8.0.10 DST=192.168.1.1
Ekiga for userB is trying to send signals to the LAN address
of userA, which is why userB cannot send signals back to userA
over VPN. But userB shouldn't be able to see the LAN address
of userA. I'm guessing Ekiga is sending this. And again notice
that it's saying both interfaces are tun() when the first one
is eth().
The correct thing to do, which all other programs do
correctly over VPN, is for Ekiga to only use the tun()
interface for sending signals out. If you connect to more
interfaces, such more VPNs, it will do this for each one.
When this is fixed, it will be a nice, easy way of using VOIP
to communicate with anyone through VPN. The most difficult
part is setting up VPN, which is pretty straightforward if
following step-by-step the server guide for Ubuntu 12.04.
Ekiga using direct connect over LAN is easy, so fixing this
bug will make Ekiga into a nice skype alternative for people
who are capable of setting up a VPN using OpenVPN.
_______________________________________________ ekiga-list mailing
list ekiga-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-list
-------------------------
Damien SANDRAS
Ekiga Project
http://www.ekiga.org _______________________________________________
ekiga-list mailing list
ekiga-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-list
