IAX2 Over OpenVPN Connection…. Working But

Home » Asterisk Users » IAX2 Over OpenVPN Connection…. Working But
Asterisk Users 3 Comments

So a friend of mine and I setup a static key based point to point OpenVPN connection from my box to his for the express intent of carrying IAX traffic encrypted.

His network on his lan is and mine is His PBX is located at and mine is at We had an existing working IAX trunk in place prior to the VPN, and after we brought the VPN up we set the host= parameter within Asterisk accordingly on each end to match the local IP’s and discovered it did not work. The trunk remained in an UNKNOWN status on each end, even though we could ping each box locally, SSH, and even SIP worked.

Here’s where I am baffled and I am hoping someone with intricate knowledge of this implementation may be able to explain it to me. What we had to do to get this working was to set the host= parameter to the respective endpoint IP’s of the VPN tunnel, in my case, and in his case. Calls flow normally now and we cannot understand how or why. I would have assumed with a destination of either LAN as defined by the routing table it would have left out on the OpenVPN
connection by default, and what’s even more strange is that IAX is the only protocol that does not appear to function as intended.

Any takers? 🙂


3 thoughts on - IAX2 Over OpenVPN Connection…. Working But

  • My guess is asterisk is replying using the tunnel ip address which your original box won’t accept unless you actually sent to that address. Thats what I see on our remote openvpn tunnels. If you want to know whats going on use tcpdump to check packets through the tunnel.

  • First, not so much of an answer but more of a question. Why use IAX2
    in your scenario? SIP would seem to be very logical in this case if you already tested it and it works.

    IAX2 really only has merits where NAT and multiple ports are an issue. It has been known to create many problems and headaches.

    Since OpenVPN negates the multiple ports over the web, and NAT isn’t a problem from what you have stated, why even bother with IAX2?

    To cleanly solve your issue, create an OpenVPN tunnel directly between the boxen with the same IP/subnet scheme. That is what I would do, as each tunnel is a “subinterface” of sorts, there is no need to keep the addressing scheme of your LANs. SIP and IAX2 should both work for you
    (I still suggest SIP). Creating a separate subnet for your OpenVPN
    connection will arguably also add a bit of security between networks.

    What does your IPtables look like? Maybe you are blocking IAX? Turn of debugging and post verbose.

    Thanks, Steve T

  • Yes, I’ve seen this same problem. It has two possible solutions.

    The reason for the problem is this: IAX2 (the Asterisk implementation, at least) depends on the “source” address in the UDP packet it receives, to know which connection the packet is part of. When it talks to a peer, it expects to see the packets arrive from the peer with a source address which matches what it understands the peer’s address to be. Packets arriving from “unknown” addresses, are simply dropped on the floor (considered to be misrouted, misconfigured, or forged, I think).

    Normally, the Asterisk IAX2 implementation does not bind itself to a single network interface. It will receive UDP packets to the IAX2 port, arriving from any interface.

    And, when it sends an IAX2 UDP packet, it simply sends it out through the socket which is bound to the
    “any interface” port.

    Because the socket isn’t bound to a specific interface, it doesn’t have a specific IP address associated with it. The Linux kernel chooses an IP address to put into the UDP packet “source” field, and the one it chooses is the IP address of the interface on which it is transmitting the packet.

    In the scenario that’s being described here, an address result mismatches. Each system is transmitting UDP packets
    *to* the “primary” or “official” or “public” interface on its peer… and these packets are being transmitted by the Linux kernel on the OpenVPN interface, and are being given the system’s OpenVPN tunnel endpoint address. In each case, when the packet arrives at the peer, the Asterisk IAX2
    stack receives the packets, finds that it has no known peer at the tunnel IP address and no IAX2 session set up for this address, and discards the packet.

    There are, I believe, two solutions which don’t involve modifying the IAX2 code in Asterisk. Both work equally well, as far as I know.

    One approach is the one you’ve taken – tell each system to
    “talk to” its peer’s OpenVPN tunnel endpoint address, rather than to the “primary” address. This eliminates the IP address mismatch. This approach works fine if both systems are connected only via this OpenVPN tunnel, and always have the same OpenVPN

    The other approach is to configure each system to bind its IAX2 port *only* to one IP interface (usually the public one), to ensure that each peer knows how to reach its peer’s public IP address (either directly, or via a route though the OpenVPN tunnel), and to tell each system to speak IAX2 to its peer’s public IP address.

    In this case, since the Asterisk socket is bound to a specific interface, all packets sent through that socket will have the bound interface’s IP address in its “source” field, and
    (once again) the address mismatch is eliminated.

    This second approach is preferable for “road warrior”
    configurations in which you might sometimes be using the OpenVPN tunnel, and sometimes not (e.g. a laptop or tablet IAX2 client which is sometimes on the corporate LAN and sometimes out on the Internet using OpenVPN).