UDP packets dropping is preventing 2-way VOIP call over an OpenVPN tunnel



  • I have a tun VPN setup between a main office running pfSense 2.0 and a remote one running tomato 1.27vpn. Almost everything works perfectly, on both sides of the tunnel clients can see each other, but the VOIP phones that I have at the remote sites can not establish a 2-way call. They are able to talk to the PBX using management ports and register with it successfully and when they receive a call the user on the remote side can hear the caller, but not the other way.

    Server config:

    
    dev ovpns7
    dev-type tun
    dev-node /dev/tun7
    writepid /var/run/openvpn_server7.pid
    #user nobody
    #group nobody
    script-security 3
    daemon
    keepalive 10 60
    ping-timer-rem
    persist-tun
    persist-key
    proto udp
    cipher BF-CBC
    up /usr/local/sbin/ovpn-linkup
    down /usr/local/sbin/ovpn-linkdown
    local xxx.xxx.xxx.xxx
    tls-server
    server 10.8.5.0 255.255.255.0
    client-config-dir /var/etc/openvpn-csc
    tls-verify /var/etc/openvpn/server7.tls-verify.php
    lport 1199
    management /var/etc/openvpn/server7.sock unix
    push "route 10.0.0.0 255.255.0.0"
    push "dhcp-option DNS 10.0.0.2"
    ca /var/etc/openvpn/server7.ca 
    cert /var/etc/openvpn/server7.cert 
    key /var/etc/openvpn/server7.key 
    dh /etc/dh-parameters.2048
    tls-auth /var/etc/openvpn/server7.tls-auth 0
    comp-lzo
    persist-remote-ip
    float
    route 10.4.0.0 255.255.255.0
    
    

    Client specific overrides on the server:

    
    iroute 10.4.0.0 255.255.255.0
    push "route 10.0.0.0 255.255.0.0 10.8.5.1"
    
    

    Client config:

    
    daemon
    client
    dev tun11
    proto udp
    remote xxx.xxx.xxx.xxx 1199
    resolv-retry 30
    nobind
    persist-key
    persist-tun
    comp-lzo adaptive
    cipher BF-CBC
    verb 3
    script-security 2
    up updown.sh
    down updown.sh
    tls-auth static.key 1
    ca ca.crt
    cert client.crt
    key client.key
    status-version 2
    status status
    
    

    If I do a packet capture on the server I get the following

    
    00:58:11.364298 AF IPv4 (2), length 232: (tos 0xc0, ttl 64, id 2372, offset 0, flags [none], proto ICMP (1), length 228)
        10.8.5.6 > 10.0.0.141: ICMP 10.8.5.6 udp port 8000 unreachable, length 208
    	(tos 0x0, ttl 127, id 0, offset 0, flags [DF], proto UDP (17), length 200)
        10.0.0.141.12124 > 10.8.5.6.8000: [udp sum ok] UDP, length 172
    	MPLS extension v15 packet not supported
    
    

    and for the same call on the client I get

    
    Jan 29 00:58:56 unknown user.warn kernel: ACCEPT IN=br0 OUT=tun11 SRC=10.4.0.112 DST=10.0.0.141 LEN=200 TOS=0x04 PREC=0x00 TTL=63 ID=16158 PROTO=UDP SPT=8000 DPT=8000 LEN=180
    
    

    If I run nmap against the PBX addresses I can see the ports 1718 and 1720 (H.323) as open, so I'm thinking that there's a problem routing UDP traffic through the VPN.

    The main site router has the following firewall rule on the WAN interface

    
    Proto	Source	Port	Destination	Port	Gateway	Queue	Schedule	Description
    UDP	 *	 *	 WAN address	 1199	 *	 none	  	 10.4.0.0/24 - OpenVPN 
    
    

    and a rule generated by the wizard for the OpenVPN

    
    Proto	Source	Port	Destination	Port	Gateway	Queue	Schedule	Description
    *	 *	 *	 *	 *	 *	 none	  	 OpenVPN wizard
    
    

    I'm completely stuck now, I've tried switching to TAP but that didn't work, tried a dozen or so different client specific overrides and custom configuration options with all of the possible permutations, all with the same outcome. I'd really appreciate any help that anyone can offer.

    Thanks.



  • You can ping no problem across the VPN?

    This is indicative of what the issue is:
    00:58:11.364298 AF IPv4 (2), length 232: (tos 0xc0, ttl 64, id 2372, offset 0, flags [none], proto ICMP (1), length 228)
        10.8.5.6 > 10.0.0.141: ICMP 10.8.5.6 udp port 8000 unreachable, length 208

    Port unreachable either means the target device is rejecting the traffic, or something that's filtering is rejecting the traffic. I'm guessing 8000 was your RTP port in that case, but not enough there to tell that for sure. Usually RTP would be in the range of 10000-20000, maybe the phone is only accepting RTP in that range and rejecting 8000. Maybe the firewall rules on Tomato are rejecting 8000. Could be something else in the network.



  • The PBX has 3 IP addresses, 1 is on a SIP trunking card (10.0.0.142) and the other two are on the processor board (10.0.0.140 & 141), I can ping all 3 from within the LAN and from over the VPN.

    Your guess is correct, 8000 is the first of 64 RTP ports. I don't know if I mentioned this but the phones do work when plugged into the local network.

    I had considered Tomato might be rejecting traffic, but the

    10.8.5.6 > 10.0.0.141: ICMP 10.8.5.6 udp port 8000 unreachable

    led me to believe that it was on the pfSense side.



  • IIRC Tomato is pretty limited in what it lets you do, though I believe the last time I worked on it I was able to upload a tcpdump binary to it for troubleshooting purposes (it wasn't included). You'll need to trace that unreachable back to find out where it's being generated. I would start on the br0 interface (should be "LAN") on Tomato and see what it's showing. If you're getting the unreachable back there sourced from the phone's MAC, it's coming straight from the phone. If you're not, keep moving your capture to different reference points until you find what's generating it.



  • Thanks for the advice cmb. I loaded tcpdump into my tomato router and when I try to make a call I get several packets that look like this one showing up on the OpenVPN tunnel

    
    52	3.917411	10.8.5.6	10.0.0.141	ICMP	244	Destination unreachable (Port unreachable)[Packet size limited during capture]
    
    

    all of which use 12244 as the source port and 8000 as the destination, which matches the capture that I had done on my pfSense router.

    I could be wrong, but if this traffic is making it out of the LAN interface on the remote site and to the VPN interface where for some reason they are denied it suggests to me that the router at the other end is blocking it. There is only a firewall rule to allow UDP WAN traffic on port 1199, as was mentioned previously.

    Next I ran a capture on the WAN interface of the pfSense router and everything looks fine there, but then when I ran another on the LAN interface I get the same packets as before showing destination unreachable, along with several other successful packets like these:

    
    196	4.040371	10.8.5.6	10.0.0.141	UDP	214	Source port: 1024  Destination port: 12026
    197	4.041143	10.0.0.141	10.8.5.6	UDP	214	Source port: 12026  Destination port: irdmi
    
    


  • Same thing show up when you tcpdump on br0? (or whatever the LAN-facing interface is on Tomato, IIRC it's br0). If it shows up on br0, it's being generated by the phone. If it only shows up on the tunnel interface on that side, it's being generated by Tomato.



  • No, not on br0 (that is the LAN interface), only on the tunnel interface. So you're saying in that case that the Tomato router is generating the unreachable destination ICMP packet? If that's the case would they also be seen on the pfSense side? Because as mentioned, I do see them in the capture performed on its LAN interface.



  • From what you've shown, it has to be from either the phone or Tomato. If you don't see it on the LAN of Tomato and do on the tunnel, then it's Tomato itself generating that. The other alternative when you're seeing it there on the tunnel would be the phone sending it, in which case you'd see it on br0 too. Not seeing it on br0 eliminates the phone. I would presume the cause to be iptables rejecting it, and that's probably the most likely, but I only know enough about Tomato to be dangerous. There may be other things in it that can reject traffic.



  • The Tomato iptables are

    
    Chain INPUT (policy DROP)
    target     prot opt source               destination         
    ACCEPT     0    --  0.0.0.0/0            0.0.0.0/0           
    DROP       0    --  0.0.0.0/0            x.x.x.x         
    DROP       0    --  0.0.0.0/0            0.0.0.0/0           state INVALID 
    ACCEPT     0    --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
    ACCEPT     0    --  0.0.0.0/0            0.0.0.0/0           
    ACCEPT     0    --  0.0.0.0/0            0.0.0.0/0           
    
    Chain FORWARD (policy DROP)
    target     prot opt source               destination         
    ACCEPT     0    --  0.0.0.0/0            0.0.0.0/0           
    ACCEPT     0    --  0.0.0.0/0            0.0.0.0/0           
    DROP       0    --  0.0.0.0/0            0.0.0.0/0           state INVALID 
    TCPMSS     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x06/0x02 tcpmss match 1461:65535 TCPMSS set 1460 
    ACCEPT     0    --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
    wanin      0    --  0.0.0.0/0            0.0.0.0/0           
    wanout     0    --  0.0.0.0/0            0.0.0.0/0           
    ACCEPT     0    --  0.0.0.0/0            0.0.0.0/0           
    upnp       0    --  0.0.0.0/0            0.0.0.0/0           
    ACCEPT     0    --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
    ACCEPT     0    --  10.8.5.0/24          0.0.0.0/0           
    REJECT     0    --  0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable 
    
    Chain OUTPUT (policy ACCEPT)
    target     prot opt source               destination         
    
    Chain upnp (1 references)
    target     prot opt source               destination         
    
    Chain wanin (1 references)
    target     prot opt source               destination         
    ACCEPT     tcp  --  0.0.0.0/0            10.4.0.107          tcp dpt:47888 
    ACCEPT     udp  --  0.0.0.0/0            10.4.0.107          udp dpt:47888 
    ACCEPT     tcp  --  0.0.0.0/0            10.4.0.107          tcp dpt:47808 
    ACCEPT     udp  --  0.0.0.0/0            10.4.0.107          udp dpt:47808 
    ACCEPT     udp  --  0.0.0.0/0            10.4.0.1            udp dpt:1199 
    
    Chain wanout (1 references)
    target     prot opt source               destination
    
    

    and now that I look at them the rule for "reject-with icmp-port-unreachable" stands out. Unfortunately I had to take the phone back to work so I'll have to bring another one home tomorrow to test it after removing that rule.



  • Thanks to cmb this is now working. The trick was to change the mode from Automatic to Custom in VPN Tunneling->Client->Firewall, and add the following iptables rules under Administration->Scripts->Firewall:

    
    # apply forwarding for OpenVPN Tunneling
    iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
    iptables -A FORWARD -s 10.8.5.0/24 -j ACCEPT
    iptables -A FORWARD -s 10.0.0.0/16 -j ACCEPT
    iptables -A FORWARD -j REJECT
    
    # enable forwarding
    echo 1 > /proc/sys/net/ipv4/ip_forward
    
    

    Thanks again.

    Now I just have to figure out how to mark this thread as solved.


Log in to reply