SIP error with FreePBX / OpenVPN

Hello,

We are a small business with 3 offices, and 3 FreePBX servers (The FreePBX Distro 2.210.62-2 i386). We are upgrading from the last version of Trixbox. Outside of a couple gotchas, the system is working fine with our IAX2 trunks, and POTS connections. Everything under Trixbox was working perfectly.

I am also running an OpenVPN network connecting the three offices, and a couple homes of special users.

I have stumbled across a problem in FreePBX that worked perfectly in Trixbox… and that is if an Aastra telephone has to use an OpenVPN connection to reach the FreePBX server. We do this for a couple special people who have a VoIP phone at their house.

AASTRA PHONE <=== OpenVPN ===> FREEPBX

The AASTRA finds the server, and can receive the config files from /tftpboot and loads up fine on the server:

Sip Show Peers:
351/351 192.168.155.20 D A 5060 OK (95 ms)

But if I try to make a call with that phone, or try to check voicemail, it will connect briefly, and then suddenly disconnect.

I look at the logs, and see a note about critical packets:

no reply to our critical packet (see https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions)

Before I take the gloves off, I want to ensure there is something real going on here… like I said, Trixbox did not have this issue.

I did upgrade the firmware on the Aastra 9112i as a part of this process.

In the office, this phone works just fine.

Any thoughts?

Thanks.

It’s NAT, it is almost always NAT. read all the posts here about it.

Do you have the VPN’s enumerated in the localnet settings in the SIP settings module?

Hello Skyking,

So that is what Local Networks really means. I put the subnets of the VPNs in there, and just enjoyed a 15 minute conversation. Beautiful. But I am in the office, where I have subnet to subnet VPN operations defined.

Our road warriors do not have a full subnet VPN defined… basically their laptops are end nodes, so I may have to get creative in this box.

Thank you.

Christian

The “dial up” VPN users still should pull from an address pool that is contiguous.