Topic: OpenVPN / Asterisk routing issue

[ReetP]

Thanks to some sterling advice from Daniel I have smeserver-openvpn-routed installed on SME v9 in server gateway mode. The server runs on a VM.

It currently runs ipsec and asterisk quite happily via the 'dummy' internal network interface 192.168.98.0

I have been trying to see if I can get my mobiles to connect and use Asterisk as well. I can get a connection, browse the net etc (that I don't really need) but I get the one way audio hell with Asterisk

I believe this is probably due to some pixie dust missing somewhere

Using the standard OpenVPN client on the phone I notice that if I accept a standard configuration, I get one way audio and can see this with tcpdump.

Typical opvn config :

client
proto udp
dev tun
ca cacert.crt
cert John.crt
key John.key
remote 5.6.7.8 1194
cipher BF-CBC
user nobody
group nobody
verb 2
comp-lzo
persist-key
persist-tun
float
nobind

If in the OpenVPN client config settings I enable Use default route, all traffic seems to hit the server, and Asterisk then works correctly.

I'd rather ONLY VPN traffic went via the server if possible but after a lot of head scratching I cannot see how to correct the issue.

I have added the OpenVPN network to 'local networks' in the server-manager and added it to the Asterisk config.

Some basic data (note ifconfig looks a bit odd due to the machine being a VM) :

'Local' network is 192.168.98.0
OpenVPN network 192.168.29.0
Ipsec VPN is 192.168.10.0

[root@asterisk init.d]# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
1-2-3-4.re *               255.255.255.255 UH    0      0        0 eth0
192.168.98.0    *               255.255.255.0   U     0      0        0 eth1
192.168.29.0    *               255.255.255.0   U     0      0        0 tunvpn0
192.168.10.0    62-210-178-1.re 255.255.255.0   UG    0      0        0 eth0
default         1-2-3-4.re 0.0.0.0         UG    0      0        0 eth0


[root@asterisk httpd]# ifconfig
eth0      Link encap:Ethernet  HWaddr 52:54:00:00:15:82 
          inet addr:5.6.7.8  Bcast:5.6.7.8  Mask:255.255.255.255
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1034853 errors:0 dropped:0 overruns:0 frame:0
          TX packets:315289 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:160066951 (152.6 MiB)  TX bytes:100450575 (95.7 MiB)

eth1      Link encap:Ethernet  HWaddr 32:FB:06:61:A9:6D 
          inet addr:192.168.98.1  Bcast:192.168.98.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:600 errors:0 dropped:0 overruns:0 frame:0
          TX packets:380 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:68014 (66.4 KiB)  TX bytes:37469 (36.5 KiB)

lo        Link encap:Local Loopback 
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:17868 errors:0 dropped:0 overruns:0 frame:0
          TX packets:17868 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:7053560 (6.7 MiB)  TX bytes:7053560 (6.7 MiB)

tunvpn0   Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 
          inet addr:192.168.29.1  P-t-P:192.168.29.1  Mask:255.255.255.0
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:31907 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4592 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:4549875 (4.3 MiB)  TX bytes:2016643 (1.9 MiB)

I can ping a client e.g. :

[root@asterisk httpd]# ping 192.168.29.2
PING 192.168.29.2 (192.168.29.2) 56(84) bytes of data.
64 bytes from 192.168.29.2: icmp_seq=1 ttl=64 time=61 ms
64 bytes from 192.168.29.2: icmp_seq=2 ttl=64 time=62 ms


tcpdump shows this when I have a call going on - I think the 100.x.x.x is a double natted IP from the carrier :

myserver.co.uk.12044 > 100.97.38.100.4000: UDP, length 172

But the IP of the phone from a web query gives 176.83.81.38

Any assistance appreciated - so close and yet so far !

B. Rgds
John




openvpn.conf as generated :

port 1194
proto udp
dev tunvpn0
user openvpn
group openvpn
chroot /etc/openvpn/routed
persist-key
persist-tun
# Certificates config
dh pub/dh.pem
ca pub/cacert.pem
cert pub/cert.pem
key priv/key.pem
tls-server
plugin /usr/lib64/openvpn/plugin/lib/openvpn-auth-pam.so login

server 192.168.29.0 255.255.255.0

topology subnet

up /etc/openvpn/routed/bin/up
script-security 2
# Options
keepalive 40 180
push "dhcp-option DOMAIN mydomain.co.uk"
push "dhcp-option DNS 192.168.98.1"
push "dhcp-option WINS 192.168.98.1"

mtu-test
mssfix
passtos
comp-lzo adaptive
push "comp-lzo adaptive"

nice 5

push "route 192.168.10.0 255.255.255.0 192.168.98.1"
push "route 192.168.98.0 255.255.255.0"

management 127.0.0.1 11195 management-pass.txt

client-config-dir ccd
status-version 2
status bridge-status.txt
suppress-timestamps
verb 3

[ReetP]

As a thought, is this something to do with routes pushed by the server and/or iroute ?

Just wondering !

[Daniel B.]

Are the two routes sent from the server to the phone added to the routing table of the phone ? once the VPN is up, can your mobile ping IPs from 192.168.98.x and 192.168.10.x ?

[ReetP]

Seems not.

Note I have 'Ignore pushed routes' set to  Disabled and 'Bypass VPN for local networks' Enabled (seems to be the default setting)

Pull Settings 'Requests IP addresses, routes and timing options from the server' is Enabled

With 'IPv4 Use default route' set on :

u0_a226@slte:/ $ ip route
100.101.55.0/24 dev rmnet0 proto kernel scope link src 100.101.55.79
192.168.29.0/24 dev tun0 proto kernel scope link src 192.168.29.2
u0_a226@slte:/ $ ping 192.168.98.1
PING 192.168.98.1 (192.168.98.1) 56(84) bytes of data.
64 bytes from 192.168.98.1: icmp_seq=1 ttl=64 time=90.0 ms
64 bytes from 192.168.98.1: icmp_seq=2 ttl=64 time=92.0 ms
64 bytes from 192.168.98.1: icmp_seq=3 ttl=64 time=88.2 ms
^C
--- 192.168.98.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 88.200/90.086/92.050/1.610 ms
u0_a226@slte:/ $ ping 192.168.10.1
PING 192.168.10.1 (192.168.10.1) 56(84) bytes of data.
From 10.25.9.177: icmp_seq=1 Time to live exceeded
From 10.25.9.177: icmp_seq=2 Time to live exceeded
From 10.25.9.177: icmp_seq=3 Time to live exceeded
^C
--- 192.168.10.1 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2002ms

Connection log :
@40000000560cf687072f16a4 176.83.85.55:21177 TLS: Initial packet from [AF_INET]176.83.85.55:21177, sid=99385ca2 2dec8967

@40000000560cf6890aabaaa4 176.83.85.55:21177 PLUGIN_CALL: POST /usr/lib64/openvpn/plugin/lib/openvpn-auth-pam.so/PLUGIN_AUTH_USER_PASS_VERIFY status=0
@40000000560cf6890aac9504 176.83.85.55:21177 TLS: Username/Password authentication succeeded for username 'roadwarrior'
@40000000560cf6890aae757c 176.83.85.55:21177 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
@40000000560cf6890aaedef4 176.83.85.55:21177 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
@40000000560cf6890aafb9b4 176.83.85.55:21177 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
@40000000560cf6890ab0138c 176.83.85.55:21177 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
@40000000560cf6890ff11f94 176.83.85.55:21177 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
@40000000560cf6890ff1c78c 176.83.85.55:21177 [John-Android] Peer Connection Initiated with [AF_INET]176.83.85.55:21177
@40000000560cf6890ff3b7a4 MULTI: new connection by client 'John-Android' will cause previous active sessions by this client to be dropped.  Remember to use the --duplicate-cn option if you want multiple clients using the same certificate or username to concurrently connect.
@40000000560cf6890ff457cc MULTI_sva: pool returned IPv4=192.168.29.2, IPv6=(Not enabled)
@40000000560cf6890ff50f64 MULTI: Learn: 192.168.29.2 -> John-Android/176.83.85.55:21177
@40000000560cf6890ff56d24 MULTI: primary virtual IP for John-Android/176.83.85.55:21177: 192.168.29.2
@40000000560cf68a1334aa04 John-Android/176.83.85.55:21177 NOTE: Beginning empirical MTU test -- results should be available in 3 to 4 minutes.
@40000000560cf68a1792b8ac John-Android/176.83.85.55:21177 PUSH: Received control message: 'PUSH_REQUEST'
@40000000560cf68a1793648c John-Android/176.83.85.55:21177 send_push_reply(): safe_cap=940
@40000000560cf68a17942fac John-Android/176.83.85.55:21177 SENT CONTROL [John-Android]: 'PUSH_REPLY,dhcp-option DOMAIN myserver.co.uk,dhcp-option DNS 192.168.98.1,dhcp-option WINS 192.168.98.1,comp-lzo adaptive,route 192.168.10.0 255.255.255.0 192.168.98.1,route 192.168.9.0 255.255.255.0 192.168.98.1,route 192.168.98.0 255.255.255.0,route-gateway 192.168.29.1,topology subnet,ping 40,ping-restart 180,ifconfig 192.168.29.2 255.255.255.0' (status=1)
@40000000560cf74619314d7c John-Android/176.83.85.55:21177 NOTE: Empirical MTU test completed [Tried,Actual] local->remote=[1541,1541] remote->local=[1541,1541]

With 'IPv4 Use default route' set off :

u0_a226@slte:/ $ ip route
100.101.55.0/24 dev rmnet0 proto kernel scope link src 100.101.55.79
192.168.29.0/24 dev tun0 proto kernel scope link src 192.168.29.2
u0_a226@slte:/ $ ping 192.168.98.1
PING 192.168.98.1 (192.168.98.1) 56(84) bytes of data.
64 bytes from 192.168.98.1: icmp_seq=1 ttl=64 time=879 ms
64 bytes from 192.168.98.1: icmp_seq=2 ttl=64 time=88.3 ms
64 bytes from 192.168.98.1: icmp_seq=3 ttl=64 time=96.4 ms
64 bytes from 192.168.98.1: icmp_seq=4 ttl=64 time=85.4 ms
64 bytes from 192.168.98.1: icmp_seq=5 ttl=64 time=102 ms
^C
--- 192.168.98.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 85.450/250.468/879.118/314.385 ms
u0_a226@slte:/ $ ping 192.168.10.1
PING 192.168.10.1 (192.168.10.1) 56(84) bytes of data.
From 10.25.9.177: icmp_seq=1 Time to live exceeded
From 10.25.9.177: icmp_seq=2 Time to live exceeded
From 10.25.9.177: icmp_seq=3 Time to live exceeded
^C
--- 192.168.10.1 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2010ms
pipe 2

Connection log :

@40000000560cf55732a080ac 176.83.85.55:20971 TLS: Initial packet from [AF_INET]176.83.85.55:20971, sid=671ed375 9dc0633b

@40000000560cf55a091be2e4 176.83.85.55:20971 PLUGIN_CALL: POST /usr/lib64/openvpn/plugin/lib/openvpn-auth-pam.so/PLUGIN_AUTH_USER_PASS_VERIFY status=0
@40000000560cf55a091ccd44 176.83.85.55:20971 TLS: Username/Password authentication succeeded for username 'roadwarrior'
@40000000560cf55a091eb1a4 176.83.85.55:20971 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
@40000000560cf55a091f1f04 176.83.85.55:20971 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
@40000000560cf55a091ff9c4 176.83.85.55:20971 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
@40000000560cf55a0920539c 176.83.85.55:20971 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
@40000000560cf55a0e71885c 176.83.85.55:20971 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
@40000000560cf55a0e726ed4 176.83.85.55:20971 [John-Android] Peer Connection Initiated with [AF_INET]176.83.85.55:20971
@40000000560cf55a0e74283c MULTI: new connection by client 'John-Android' will cause previous active sessions by this client to be dropped.  Remember to use the --duplicate-cn option if you want multiple clients using the same certificate or username to concurrently connect.
@40000000560cf55a0e74c864 MULTI_sva: pool returned IPv4=192.168.29.2, IPv6=(Not enabled)
@40000000560cf55a0e757ffc MULTI: Learn: 192.168.29.2 -> John-Android/176.83.85.55:20971
@40000000560cf55a0e761c3c MULTI: primary virtual IP for John-Android/176.83.85.55:20971: 192.168.29.2
@40000000560cf55b19f7aea4 John-Android/176.83.85.55:20971 PUSH: Received control message: 'PUSH_REQUEST'
@40000000560cf55b19f8b844 John-Android/176.83.85.55:20971 send_push_reply(): safe_cap=940
@40000000560cf55b19fac3b4 John-Android/176.83.85.55:20971 SENT CONTROL [John-Android]: 'PUSH_REPLY,dhcp-option DOMAIN myserver.co.uk,dhcp-option DNS 192.168.98.1,dhcp-option WINS 192.168.98.1,comp-lzo adaptive,route 192.168.10.0 255.255.255.0 192.168.98.1,route 192.168.9.0 255.255.255.0 192.168.98.1,route 192.168.98.0 255.255.255.0,route-gateway 192.168.29.1,topology subnet,ping 40,ping-restart 180,ifconfig 192.168.29.2 255.255.255.0' (status=1)
@40000000560cf55d33007afc John-Android/176.83.85.55:20971 NOTE: Beginning empirical MTU test -- results should be available in 3 to 4 minutes.
@40000000560cf614073b47bc John-Android/176.83.85.55:20971 NOTE: Empirical MTU test completed [Tried,Actual] local->remote=[1541,1541] remote->local=[1541,1541]

I can then see asterisk struggling with this from tcpdump :

11:19:13.523932 IP asterisk.myserver.co.uk.10312 > 100.101.55.79.4000: UDP, length 172

Not sure whether this is a routing or a iptables problem.

Any help appreciated !

[ReetP]

Something I should mention....

Note I have a couple of iptables rules for ipsec set in the masq file. I am wondering if they have any influence. Unfortunately I can't disable them to test until the weekend when no one is using the system.

These rules SHOULD only affect ipsec traffic.

40AllowIpsec
#Allow ipsec traffic
iptables -A INPUT -m policy --dir in --pol ipsec -j ACCEPT
iptables -A FORWARD -m policy --dir in --pol ipsec -j ACCEPT

#This probably duplicates --pol ipsec above

iptables -A INPUT -p udp --dport 500 -j ACCEPT
iptables -A INPUT -p udp --dport 4500 -j ACCEPT

#Do not NAT VPN traffic
/sbin/iptables -t nat -I POSTROUTING -m policy --dir out --pol ipsec -j ACCEPT
/sbin/iptables -A FORWARD -m policy --dir in --pol ipsec -j ACCEPT

[Daniel B.]

u0_a226@slte:/ $ ping 192.168.10.1
PING 192.168.10.1 (192.168.10.1) 56(84) bytes of data.
From 10.25.9.177: icmp_seq=1 Time to live exceeded
From 10.25.9.177: icmp_seq=2 Time to live exceeded
From 10.25.9.177: icmp_seq=3 Time to live exceeded

No need to look further: your phone doesn't send packets for 192.168.10.x through the VPN (it should use 192.168.98.1 as gateway for this network). For some reason, it ignores what the server is sending. You need to fixe that

[ReetP]

No need to look further: your phone doesn't send packets for 192.168.10.x through the VPN (it should use 192.168.98.1 as gateway for this network). For some reason, it ignores what the server is sending. You need to fixe that

Trying

I did wonder about using iroute

I added client-to-client to openvpn.conf
I then created a file with the same name as the client in ccd/John-Android

iroute 192.168.10.0 255.255.255.0
iroute 192.168.98.0 255.255.255.0
iroute 192.168.29.0 255.255.255.0


Logs shows this :

@40000000560d15962bd703cc 176.83.17.92:12499 TLS: Initial packet from [AF_INET]176.83.17.92:12499, sid=a0c67794 05d82d76

@40000000560d15982f17e2a4 176.83.17.92:12499 PLUGIN_CALL: POST /usr/lib64/openvpn/plugin/lib/openvpn-auth-pam.so/PLUGIN_AUTH_USER_PASS_VERIFY status=0
@40000000560d15982f18c91c 176.83.17.92:12499 TLS: Username/Password authentication succeeded for username 'roadwarrior'
@40000000560d15982f1aad7c 176.83.17.92:12499 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
@40000000560d15982f1b16f4 176.83.17.92:12499 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
@40000000560d15982f1bf1b4 176.83.17.92:12499 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
@40000000560d15982f1c47a4 176.83.17.92:12499 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
@40000000560d159833110d2c 176.83.17.92:12499 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
@40000000560d15983311c8ac 176.83.17.92:12499 [John-Android] Peer Connection Initiated with [AF_INET]176.83.17.92:12499
@40000000560d15983313ff14 MULTI: new connection by client 'John-Android' will cause previous active sessions by this client to be dropped.  Remember to use the --duplicate-cn option if you want multiple clients using the same certificate or username to concurrently connect.
@40000000560d159833149384 OPTIONS IMPORT: reading client specific options from: ccd/John-Android
@40000000560d15983316ae94 MULTI_sva: pool returned IPv4=192.168.29.2, IPv6=(Not enabled)
@40000000560d1598331771e4 MULTI: Learn: 192.168.29.2 -> John-Android/176.83.17.92:12499
@40000000560d15983317cfa4 MULTI: primary virtual IP for John-Android/176.83.17.92:12499: 192.168.29.2
@40000000560d159833182594 MULTI: internal route 192.168.29.0/24 -> John-Android/176.83.17.92:12499
@40000000560d159833188354 MULTI: Learn: 192.168.29.0/24 -> John-Android/176.83.17.92:12499
@40000000560d15983318d55c MULTI: internal route 192.168.98.0/24 -> John-Android/176.83.17.92:12499
@40000000560d159833192f34 MULTI: Learn: 192.168.98.0/24 -> John-Android/176.83.17.92:12499
@40000000560d15983319813c MULTI: internal route 192.168.10.0/24 -> John-Android/176.83.17.92:12499
@40000000560d15983319d72c MULTI: Learn: 192.168.10.0/24 -> John-Android/176.83.17.92:12499
@40000000560d1598331a92ac REMOVE PUSH ROUTE: 'route 192.168.98.0 255.255.255.0'
@40000000560d159939a8008c John-Android/176.83.17.92:12499 NOTE: Beginning empirical MTU test -- results should be available in 3 to 4 minutes.
@40000000560d159939a96bd4 John-Android/176.83.17.92:12499 PUSH: Received control message: 'PUSH_REQUEST'
@40000000560d159939a9ecbc John-Android/176.83.17.92:12499 send_push_reply(): safe_cap=940
@40000000560d159939aaa454 John-Android/176.83.17.92:12499 SENT CONTROL [John-Android]: 'PUSH_REPLY,dhcp-option DOMAIN myserver.co.uk,dhcp-option DNS 192.168.98.1,dhcp-option WINS 192.168.98.1,comp-lzo adaptive,route 192.168.10.0 255.255.255.0 192.168.98.1,route-gateway 192.168.29.1,topology subnet,ping 40,ping-restart 180,ifconfig 192.168.29.2 255.255.255.0' (status=1)

Still doesn't fix it though    Can't ping anything including 192.168.98.x (I should add it to the Wiki page)

I think the issue is to do with NAT in some way. We can forget the other networks e.g. 192.168.10.x which are really irrelevant.

Asterisk is receiving a packet from 10.x.x.x and tries to return it but something somewhere doesn't know how to route it.

e.g. I think this is the RTP packet coming from Asterisk
asterisk.impamark.co.uk.13208 > 10.221.92.45.4002: UDP, length 172

It SHOULD be something like

asterisk.impamark.co.uk.13208 > 192.168.29.2.4002: UDP, length 172


I was looking at stuff like this :

https://community.openvpn.net/openvpn/wiki/BridgingAndRouting

Just don't get it though... the grey cells are struggling !

[ReetP]

I think this is the core of it - the connection is being NAT'd but needs really to be plain routed somehow ?

https://openvpn.net/index.php/access-server/docs/admin-guides/215-how-to-setup-routing-in-openvpn-access-server.html

Odd cos Asterisk knows the VPN IP address of the mobile :

8202/8202                 192.168.29.2                             D              A  51756    OK (89 ms)

I can ping the mobile from the CL

[root@asterisk openvpn.conf]# ping 192.168.29.2
PING 192.168.29.2 (192.168.29.2) 56(84) bytes of data.
64 bytes from 192.168.29.2: icmp_seq=1 ttl=64 time=257 ms

And can ping the server from the phone

ping 192.168.98.1
64 bytes from 192.168.98.1 blah blah

Grrrrrr..............

[Daniel B.]

Asterisk is receiving a packet from 10.x.x.x and tries to return it but something somewhere doesn't know how to route it.

That seems unlikely, as 10.X.X.X are unroutable. check with tcpdump if this is comming in through the VPN or directly from the WAN. Anyway, my guess is that the issue is with your SIP client on the phone. In SIP/RTP, IP address of peers are sent in the paylod of the packet so the other peer can establish the return path. This means that the client can send packets using 192.168.29.2 but say asterisk to reach him with it's WAN IP (10.221.92.45, which is the IP given by your ISP, and isn't routable on the internet). Check your client's setting if you can bind it to a specific IP or interface

[ReetP]

That seems unlikely, as 10.X.X.X are unroutable. check with tcpdump if this is comming in through the VPN or directly from the WAN. Anyway, my guess is that the issue is with your SIP client on the phone. In SIP/RTP, IP address of peers are sent in the paylod of the packet so the other peer can establish the return path. This means that the client can send packets using 192.168.29.2 but say myserver to reach him with it's WAN IP (10.221.92.45, which is the IP given by your ISP, and isn't routable on the internet). Check your client's setting if you can bind it to a specific IP or interface

Yes, I know it is unrouteable - it is a double natted address from the ISP I think. The phones IP address seems to be 10.221.92.45

u0_a226@slte:/ $ ip route
10.221.92.0/24 dev rmnet0 proto kernel scope link src 10.221.92.45

If I try "what's my IP" it currently shows the carriers external address which is 176.83.17.92 at this moment in time.

At the same time in a call I get this :

tcpdump | grep 10\.221    (I presume this is just looking on the eth0 interface by default)

15:19:12.434137 IP myserver.co.uk.16436 > 10.221.92.45.4000: UDP, length 172
15:19:12.455090 IP myserver.co.uk.16436 > 10.221.92.45.4000: UDP, length 172

So that is the server trying to send the RTP packets (usually ports between 10,000 - 20,000) to the actual IP of the phone, not it's VPN address.

I can also see this

tcpdump -i tunvpn0

15:23:33.180037 IP 192.168.29.2.49859 > myserver.co.uk.5060: SIP, length: 2
15:23:49.965351 IP 192.168.29.1.5060 > 192.168.29.2.49859: SIP, length: 548
15:23:50.798573 IP 192.168.29.2.49859 > 192.168.29.1.5060: SIP, length: 1120
15:24:14.939245 IP 192.168.29.2.49859 > myserver.co.uk.5060: SIP, length: 2

So the port 5060 packets are routing correctly, but not the UDP RTP ones.

If I then turn on 'Use default route" in the client to redirect traffic over the VPN I can then see this

tcpdump -i tunvpn0

15:29:45.539216 IP 192.168.29.2.4000 > 192.168.29.1.10462: UDP, length 172
15:29:45.558626 IP 192.168.29.1.10462 > 192.168.29.2.4000: UDP, length 172
15:29:45.575064 IP 192.168.29.2.4000 > 192.168.29.1.10462: UDP, length 172

Now the TCP is going over the VPN and sound works as expected.

Quite frankly I have no idea !

I'd much prefer JUST the VPN traffic through the server (and that SHOULD work) but can live without. It would be much better to understand and fix the issue though

[Daniel B.]

And I still think this is a problem in your SIP client. It probably have a function which detects which local IP can reach its default gateway, and send this IP in its SIP/RTP packets. Which SIP client are you using, and doesn't it have a setting to bind to a particular IP (or interface) ?

[ReetP]

And I still think this is a problem in your SIP client. It probably have a function which detects which local IP can reach its default gateway, and send this IP in its SIP/RTP packets. Which SIP client are you using, and doesn't it have a setting to bind to a particular IP (or interface) ?

Sorry I misread you and thought you meant openvpn client.

Am using csipsimple currently.

Only thing I can see about this is using the 'local' account. I tried that but it doesn't seem to want to play ball either can't get it to make a call at the minute.

[ReetP]

AHHHHHHHHHHHHH !!!!!!!!!!!!!!!

Got it I think.

I finally used cSipSimple Expert mode.

I didn't do anything apart from the default settings.

My extension is 8202
My server is 192.168.98.1

Account Name - Some name
Account id - 8202 <sip8202@192.168.98.1>
Registration URI - sip:192.168.98.1:5060
Realm *
Username 8202
Data (Password) - yourLongPassword
Proxy URI - sip:192.168.98.1:5060

I know that in the OpenVPN client I can turn on Use Default Route if I want all traffic to pass through.

Many thanks to Daniel for his eternal patience with a dumb schmuck

B. Rgds
John