>> 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, 172.10.1.1 in my case, and >> 172.10.1.2 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.
> 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. 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 addresses. 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). -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users