Bug 32113 - Register through openvpn tunnel chooses the wrong IP
Summary: Register through openvpn tunnel chooses the wrong IP
Status: RESOLVED NOTOURBUG
Alias: None
Product: Telepathy
Classification: Unclassified
Component: rakia (show other bugs)
Version: 0.6
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Mikhail Zabaluev
QA Contact: Telepathy bugs list
URL: https://sourceforge.net/tracker/?func...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-12-05 10:19 UTC by Emiliano Castagnari
Modified: 2010-12-07 02:26 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description Emiliano Castagnari 2010-12-05 10:19:48 UTC
I am using Sofia with Empathy. When I try to register against an Asterisk PBX through an OpenVPN tunnel, the wrong IP is choosen when sending packets on the vpn interface:

The network details:

  { @sigma ~ $> ip addr
  1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
      link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
      inet 127.0.0.1/8 scope host lo
      inet6 ::1/128 scope host 
         valid_lft forever preferred_lft forever
  2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN
  qlen 1000 
      link/ether 00:24:e8:83:e5:d7 brd ff:ff:ff:ff:ff:ff
  3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP
  qlen 1000 
      link/ether 78:e4:00:6b:95:ff brd ff:ff:ff:ff:ff:ff
      inet 172.20.1.2/28 brd 172.20.1.15 scope global eth1
         valid_lft forever preferred_lft forever
  6: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast 
  state UNKNOWN qlen 100
      link/none 
      inet 10.10.2.78 peer 10.10.2.77/32 scope global tun0

  # Trimed the unnecesary routes
  { @sigma ~ $> ip route
  10.10.2.77 dev tun0  proto kernel  scope link  src 10.10.2.78 
  172.20.1.0/28 dev eth1  proto kernel  scope link  src 172.20.1.2  metric 2 
  10.10.2.0/24 via 10.10.2.77 dev tun0  proto static 
  172.16.100.0/24 via 10.10.2.77 dev tun0  proto static 
  default via 172.20.1.1 dev eth1  proto static 

The PBX is on the 172.16.100.0/24 network. So traffic should be generated from
the 10.10.2.78 to 172.16.100.254, as stated by the routing table. Trying to
register generates the following network packets. :

  { @sigma ~ $> sudo tcpdump -n -i tun0 host 172.16.100.254
  tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
  listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes
  11:40:19.311653 IP 172.20.1.2.51115 > 172.16.100.254.5060: SIP, length: 481
  11:40:19.811837 IP 172.20.1.2.51115 > 172.16.100.254.5060: SIP, length: 481
  11:40:20.811826 IP 172.20.1.2.51115 > 172.16.100.254.5060: SIP, length: 481
  11:40:22.812170 IP 172.20.1.2.51115 > 172.16.100.254.5060: SIP, length: 481
  11:40:26.812289 IP 172.20.1.2.51115 > 172.16.100.254.5060: SIP, length: 481
  11:40:30.812746 IP 172.20.1.2.51115 > 172.16.100.254.5060: SIP, length: 481
Comment 1 Mikhail Zabaluev 2010-12-07 02:26:29 UTC
This is a problem with sofia-sip.

A workaround is to use the connection parameter local-ip-address, similarly to the Maemo recipe given here:
https://bugs.maemo.org/show_bug.cgi?id=1860


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.