Re: [Ekiga-list] Bug prevents VPN use

[Konrad Karl <kk_konrad gmx at>]

On Wed, Oct 02, 2013 at 10:48:41AM +0200, Damien Sandras wrote:
> Le 02/10/13 10:15, Konrad Karl a ?crit :
> .....
> > A question still remains for me: why is this done the way it is?
> > If I e.g telnet some.ip.add.ress then routing rule apply and all
> > traffic will go over the vpn interface (tun0 or such).
>
> When you are using telnet, there is an active TCP connection between
> both peers.
> When you are using Ekiga, you are working connectionless, ie through
> UDP. That means that userB can not use the same connection to reply
> back to you. All it can do is send a SIP message to a destination IP
> and port.
>
> If user B has two local interfaces (eth0: 192.x and tun: 10.x), when
> EkigaB will send a SIP message to userA, it will send it twice
> (because it can not determine how routing will work, that's the
> kernel responsibility) :
> - one SIP message to userA through tun0 with tun0 source IP address
> to userA IP and port
> - one SIP message to userA through eth0 with eth0 source IP address
> to user IP and port

On Linux the ip command seems to be able to determine the outgoing network
interface and also the source address being used. It seems to query
the kernel routing table via netlink socket (just straced the ip
command)

ip route get 8.8.8.8: (google name server)

8.8.8.8  via 192.168.1.1 dev p36p1  src 192.168.1.10
(correct, p36p1 was eth0 in prior universe)

and

ip route get 10.100.0.30:   (openvpn)

10.100.0.30 via 10.100.0.9 dev tun0  src 10.100.0.10
(correct)

Naive question: why cannot Ekiga do something similar?

Greetings,

Konrad