Re: [Ekiga-list] Bug prevents VPN use
Le 02/10/13 13:57, Konrad Karl a crit: On Wed, Oct 02, 2013 at 10:48:41AM +0200, Damien Sandras wrote: 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? Good news... It will be implemented in next release. I'm finishing the GTK 3 port (including migration to the portable GSettings) and that's next on my TODO :) Damien SANDRAS Ekiga Project http://www.ekiga.org ___ ekiga-list mailing list ekiga-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Bug prevents VPN use
On Thu, Oct 03, 2013 at 09:29:38AM +0200, Damien Sandras wrote: Le 02/10/13 13:57, Konrad Karl a ?crit : Naive question: why cannot Ekiga do something similar? Good news... It will be implemented in next release. I'm finishing the GTK 3 port (including migration to the portable GSettings) and that's next on my TODO :) ++like for now I am using a firewall rule but this is awkward. Konrad (I am not on Facebook...) ___ ekiga-list mailing list ekiga-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Bug prevents VPN use
Le 01/10/13 20:17, Konrad Karl a crit: Hi, On Sun, Sep 29, 2013 at 05:53:58PM +0200, 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. is this behaviour required by the SIP protocol? (I also want to restrict all ekiga traffic to one specific openvpn interface at times - direct ip call w/o registration) A short explanation will be appreciated. Not specifically required. The standard says nothing about multiple interfaces handling. It is just a question of routing after that point. You can see this as a kind of fork of SIP requests. If you have two routes to the same destination, through 2 different interfaces, it should work too, but both routes have to work both ways : ie, if you can send a SIP PDU, you should be able to receive incoming requests and responses through that route too. Damien SANDRAS Ekiga Project http://www.ekiga.org ___ ekiga-list mailing list ekiga-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Bug prevents VPN use
On Wed, Oct 02, 2013 at 09:43:33AM +0200, Damien Sandras wrote: Le 01/10/13 20:17, Konrad Karl a ?crit : Hi, On Sun, Sep 29, 2013 at 05:53:58PM +0200, 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. is this behaviour required by the SIP protocol? (I also want to restrict all ekiga traffic to one specific openvpn interface at times - direct ip call w/o registration) A short explanation will be appreciated. Not specifically required. The standard says nothing about multiple interfaces handling. It is just a question of routing after that point. You can see this as a kind of fork of SIP requests. If you have two routes to the same destination, through 2 different interfaces, it should work too, but both routes have to work both ways : ie, if you can send a SIP PDU, you should be able to receive incoming requests and responses through that route too. Thanks for explanation, Damien! 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). Why not do the same with SIP? (or at least have one option for that) (confessing I am a SIP noob :-) In my case there is exactly one way to reach the destination and that is VPN. Greetings, Konrad ___ ekiga-list mailing list ekiga-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Bug prevents VPN use
Le 02/10/13 10:15, Konrad Karl a crit: Not specifically required. The standard says nothing about multiple interfaces handling. It is just a question of routing after that point. You can see this as a kind of fork of SIP requests. If you have two routes to the same destination, through 2 different interfaces, it should work too, but both routes have to work both ways : ie, if you can send a SIP PDU, you should be able to receive incoming requests and responses through that route too. Thanks for explanation, Damien! 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 One of them should work. Your mail suggests that both messages are sent using the same interface but with different source IP and ports. That's weird. The best would be that you post a -d4 output somewhere (not on the mailing list) of userB trying to reach userA so that we can determine what Ekiga is doing. Damien Damien SANDRAS Ekiga Project http://www.ekiga.org ___ ekiga-list mailing list ekiga-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Bug prevents VPN use
On Wed, 2 Oct 2013, Damien Sandras wrote: 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 One of them should work. Your mail suggests that both messages are sent using the same interface but with different source IP and ports. That's weird. How does Ekiga assure that the packet is actually sent out eth0 with eth0 source IP? By default routing and source address selection are completely decoupled and if default route is to tun0, then all packets regardless of source address will go out tun0. One has to put policy routing in place to avoid this and assure that eth0 IP packets actually go out eth0 (and then you have to have the concept of multiple default routes that might change over time that needs to influence the policy routing settings). -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ ekiga-list mailing list ekiga-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Bug prevents VPN use
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 ___ ekiga-list mailing list ekiga-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Bug prevents VPN use
Le 02/10/13 11:56, Mikael Abrahamsson a crit: On Wed, 2 Oct 2013, Damien Sandras wrote: 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 One of them should work. Your mail suggests that both messages are sent using the same interface but with different source IP and ports. That's weird. How does Ekiga assure that the packet is actually sent out eth0 with eth0 source IP? By default routing and source address selection are completely decoupled and if default route is to tun0, then all packets regardless of source address will go out tun0. One has to put policy routing in place to avoid this and assure that eth0 IP packets actually go out eth0 (and then you have to have the concept of multiple default routes that might change over time that needs to influence the policy routing settings). You are right... If Ekiga is listening on IP-A and IP-B, then it will send one SIP packet per IP. Exact routing conditions, including interface selection, are determined by the routing configuration. Damien Damien SANDRAS Ekiga Project http://www.ekiga.org ___ ekiga-list mailing list ekiga-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Bug prevents VPN use
Hi, On Sun, Sep 29, 2013 at 05:53:58PM +0200, 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. is this behaviour required by the SIP protocol? (I also want to restrict all ekiga traffic to one specific openvpn interface at times - direct ip call w/o registration) A short explanation will be appreciated. Greetings, Konrad ___ ekiga-list mailing list ekiga-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-list
[Ekiga-list] Bug prevents VPN use
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
Re: [Ekiga-list] Bug prevents VPN use
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="" DST=192.168.1.2 OUT=eth0 SRC="" 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="" DST=10.8.0.10 OUT=tun0 SRC="" 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="" DST=192.168.1.1 OUT=tun0 SRC="" 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
Re: [Ekiga-list] Bug prevents VPN use
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
