Comment 5 for bug 1058365

Leonid Evdokimov (darkk) wrote :

It's hard to tell if it's bug in Empathy, telepathy-rakia, sofia-sip or
network-manager-openvpn. Here is my case.

I have three SIP accounts: one for my company and two for personal usage, all
three accounts work in "simple" case with single global IP address without
NAT.

I have following network setup that kills SIP connection:
- my Wi-Fi is in 192.168.1.0/24 network and gives me default gateway and NAT
- my VPN gives me _global_ IPv4 and IPv6 addresses, I __don't__ use VPN as
  default gateway and route only "enterprise" networks via VPN tunnel
- my virual 10.0.1.0/24 network connects me with virtualboxes I use for
  development

When VPN is disconnected telepathy selects 192.168... address for outgoing
packets and all three SIP accounts work like charm.

When VPN is __connected__ telepathy selects VPN IP address as source address.
So, kernel routes packets via Wi-Fi network (!), not via VPN for two accounts
of three. "company" account still works as it's reachable both via VPN and
without it.

Packets routed like that may be dropped due to various reasons - NAT,
reverse-path filter, etc. The reason does not matter much.

Bottomline - there are several ways to fix the issue.

1. add proper source-based routing setup to network-manager.
   In my case all SIP calls will be routed via VPN with this configuration as
   sofia-sip library prefers VPN address over everything else.
   It's not good in terms of latency, but it works.

2. update local-ip-address in SIP settings on network connectiviy change
   I implemented NetworkManager dispatcher script that sets local-ip-address
   using IP routing table. It does not look like generic solution, but it
   works for me: https://github.com/darkk/home/blob/master/bin/nm-sofia-reroute

3. add option to sofia-sip library to disable complex source address selection
   I've not actually tried it, but the script does alike job.