Ooh323 port 1720 closed after first call

General Help
1

So far my freePBX box working well for h323 outgoing call (to all IPsec branches) & incoming call (tested in local network).

I’m having a problem when dial in from the branch office, basically first call is always successful, and then you can’t make the second call, telnet 1720 to freePBX is also failed (from any of the computer within the branch). But, telnet to port 80 with no issue. And local network remain fine for h323 dial in & dial out.

Either I have to wait for certain of time or manually restart network connection of freePBX, and then I can make another call for once from the branch.

I don’t find any issue on firewall handling the traffic, it’s seem like freePBX just don’t want to respond to port 1720 for my branch’s subnet.

I’m totally lost and don’t know why freePBX blocked port 1720 from the branch’s subnet after first call!

Below is as firewall packets captured.
Unsuccessful call:
14:42:54.495548 (authentic,confidential): SPI 0xceabaee7: IP 192.168.0.201.30001 > 192.168.2.60.1720: tcp 0
14:42:57.495738 (authentic,confidential): SPI 0xceabaee7: IP 192.168.0.201.30001 > 192.168.2.60.1720: tcp 0
14:43:03.494421 (authentic,confidential): SPI 0xceabaee7: IP 192.168.0.201.30001 > 192.168.2.60.1720: tcp 0

Successful call (192.168.2.60 response to the incoming call):
16:38:55.852897 (authentic,confidential): SPI 0xcec34a9b: IP 192.168.0.201.30006 > 192.168.2.60.1720: tcp 0
16:38:55.853261 (authentic,confidential): SPI 0xc9867203: IP 192.168.2.60.1720 > 192.168.0.201.30006: tcp 0
16:38:55.868778 (authentic,confidential): SPI 0xcec34a9b: IP 192.168.0.201.30006 > 192.168.2.60.1720: tcp 0
16:38:55.891787 (authentic,confidential): SPI 0xcec34a9b: IP 192.168.0.201.30006 > 192.168.2.60.1720: tcp 1200

  • FreePBX 13.0.192.19
  • Hyper-v virtual machine
  • PBX Firmware:10.13.66-22
  • PBX Service Pack:1.0.0.0
  • Firewall disabled
  • Intrusion Detection have whitelisted those test machine
  • H323 dial in test tool - Ekiga
2

is it always on the second call? it sounds to me like an old problem we used to chase where the router itself was closing UDP ports after a relatively short internal which means that inbound calls don’t get through the router.

3

Should I check for my router (pfSense firewall)?

I’m just wonder if I manually restart network connection of freePBX can make another call for once, I thought the issue is come from freePBX (or CentOS) itself.

Please share with me if you have any more information, I will be in this direction to test, thank you.

4

Yes, check for UDP timers.

5

Just to update, the problem resolved after I upgraded pfSense firewall from version 2.3 to the latest 2.4.2

Not really sure is this the caused. My intentions upgrade the firewall is not for this purpose.

6

pfSense had a bug with UDP packets over IPsec. Not sure if your specific situation was but here is the ticket:

https://redmine.pfsense.org/issues/7801

7

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.