VOIP thru IpSec VPN problems



  • I have two PfSense devices. One in location "A" and the other at location "B". At location "A", on the local lan, is a VOIP (FreePBX) telephone box. This VOIP box is being "hit" with phishing attempts to connect from various countries.

    When I create a firewall rule that allows only my VOIP providers ip address to connect to the VOIP box the 'hits' stop. Problem is that behind the router at location "B" are two extensions that are connected to the VOIP box via an IpSec VPN (between the two PfSense routers.) We are losing one side of the conversation. They can hear the incoming call but the incoming call cannot hear them.

    I am struggling to create firewall rules that will allow the location "B" extensions to remain connected. Suggestions?


  • LAYER 8 Netgate

    No rules you place on WAN should affect any connections over IPsec if the tunnel is still establishing.

    Are you positive the phones are connecting to the FreePBX over the VPN for both SIP and RTP?

    You might want to look at the states/packet captures/logs to be sure.



  • My location "B" extensions will dial out and receive calls but, no audio and the calls time out after 31 seconds. Clearly SIP is working but RTP is failing.

    I have adjusted "Firewall Optimization Options" to 'High-Latency' (up one level from default) on both ends.

    I have disabled "PF Scrubbing" on both ends.

    FreePBX logfile clearly states "Disconnecting call 'SIP/[sanitized4security]' for lack of RTP activity in 31 seconds" so, it is RTP failing.

    Both ends of the IPsec VPN are pfSense v2.3. Everything was working before the adjustments for location "A" to allow ONLY connection from my SIP provider ip address. Would this rule block RTP from location "B" somehow? As you stated, rules placed on WAN should not effect IPsec tunnel.

    Do I need to add a rule at location "B" to allow RTP?


  • LAYER 8 Netgate

    It is almost impossible to diagnose something like this wilout real information and screen captures, packet captures, etc.

    You can start by describing, in detail, where the:

    Phones are
    The PBX is
    The SIP trunks, of any, are.

    Preferably in relation to the PfSense node(s).

    It sounds like you broke the connection to the SIP provider and it has nothing to do with IPsec. The all need different things. If your SIP provider has any guidance for configuring a firewall that does NAT, that would also be helpful information.

    But ALL of those settings such as high-latency and no scrubbing back to the default. They are meaningless. You probably need additional port forwards, firewall rules, and maybe some static NAT ports done properly.

    Look for blocked connections from the SIP provider when you make a call that fails.



  • First, remember that everything worked until I setup my SIP provider as an alias to insert the 'alias' into the firewall rules to accept traffic ONLY from SIP provider. Once this was in place (to stop the blacklist IP address attacks) RTP stopped working for the extensions at home location "B". I can still dial a number from any extension at location "B" and receive calls from (my cellphone) to any extension at location "B". However, no voice (RTP) and all calls (to or from) time out after 31 seconds due to lack of voice connection.

    I have not broken my connection to my SIP Provider as location "A" (Office) calls are still working and do not time out.

    The IPsec tunnel is simple shared key type.

    All extensions connect to 192.168.16.222 the FreePBX box.

    Attached is a drawing (crude) and a packet capture (level of detail set at "medium") from the PfSense at "location A (office)" of the Yealink T23G extension (ip address) 192.168.242.170 at "location B".

    Your help is greatly appreciated. Thank you in advance.



    packetcapture-ext210_2017-09-18.txt


  • LAYER 8 Netgate

    Please just download and attach the pcap so wireshark can do the heavy lifting. Thanks.


  • LAYER 8 Netgate

    First, remember that everything worked until I setup my SIP provider as an alias to insert the 'alias' into the firewall rules to accept traffic ONLY from SIP provider. Once this was in place (to stop the blacklist IP address attacks) RTP stopped working for the extensions at home location "B".

    There is no way a rule on WAN at location A can impact SIP over IPsec between A & B. You must be blocking something now that needs to be passed to/from the SIP provider.  Perhaps site A and B were using the actual public IP address from B to A for RTP and not IPsec at all? Add the WAN address of Site B to the alias and see what happens.

    Check your firewall logs.



  • Thank you for your suggestion.

    Sorry, please notice that it says "newbie" below my login so, simplest of questions.

    You said "Add the WAN address of Site B to the alias and see what happens." By that you mean to add the Site B WAN Address as an alias of the site A firewall rules?

    But, that confuses me. All other computers, I have no problem ssh into, etc. through the VPN tunnel.

    I am correct in that site B should be communicating back to the FreePBX box through the IPsec tunnel NOT site B connecting to my SIP provider over the internet?


  • LAYER 8 Netgate

    No. Add it to the alias you are using to limit connections from the SIP provider. To also pass those connections from site B (if they exist).



  • Your suggestion has solved my problem. Adding the ip address of location "B" to the location "A" alias gave permission for a voice connection.

    I believe, as you have suggested, that it has to do with the extension responding to FreePBX with location "B" wan address in the RTP requests strings. As PfSense would allow ONLY my SIP provider then PfSense was rejecting the extensions RTP request.

    Thank you. Your patience and help are greatly appreciated.


  • LAYER 8 Netgate

    Glad that worked.

    There is probably something in the PBX that will treat the site B subnet as an inside subnet so it gets the PBX's inside address in the SIP/RTP requests so that site connects over the VPN instead of over the WAN.

    It would probably be a good idea to fix that.



  • I'm using an older version of FreePBX with a similar setup.

    Have a look at sip_nat.conf, mine is like this:

    localnet=192.168.1.0/255.255.255.0     ;SiteA
    localnet=192.168.2.0/255.255.255.0      ;SiteB
    nat=yes
    externip=1.2.3.4
    fromdomain=example.com 
    

    You can also set similar in Settings/Asterisk SIP Settings (- my system highlights an Error because the contents are different: I've chosen to leave this, while it works, until I change the network again).

    ![Screenshot - MBA11 2017-09-22 at 23.14.53.jpg](/public/imported_attachments/1/Screenshot - MBA11 2017-09-22 at 23.14.53.jpg)
    ![Screenshot - MBA11 2017-09-22 at 23.14.53.jpg_thumb](/public/imported_attachments/1/Screenshot - MBA11 2017-09-22 at 23.14.53.jpg_thumb)



  • Yes, thank you, I am aware of this FreePBX option.

    My issue was NOT with FreePBX connecting ONLY with my SIP provider it was the extensions located through IPSec VPN that could not properly connect.

    Every situation is unique, mine more unique than many, I suspect but, the issue was PfSense (doing it's job) allowing ONLY my SIP provider to connect and NOT allowing my extensions through VPN to connect. Once the VPN alias I setup was added then, my extensions connected and worked properly.

    I appreciate your suggestion.


  • LAYER 8 Netgate

    I believe you are still missing the point. But they're your phone conversations going over the clear internet instead of the VPN so no skin off my nose.



  • I'll see what FreePBX forum thinks about this.

    But, it appears to me that this is a PfSense issue not allowing connection. I think your right that the ipaddress is being changed (probably by FreePBX) and therefore PfSense will block but, I am still working this out.

    By your comment, I just now realize that you are right the conversions could be connecting over the net.

    We'll see.


  • LAYER 8 Netgate

    Look.

    Your WAN rules have ZERO effect on connections over IPsec.

    The problem is your other site is connecting RTP over the internet instead of IPsec. That is because your PBX is giving them the public address to connect to instead of the private address that would be interesting to IPsec.

    pfSense is just doing what it is told to do.

    It's not pfSense. It is your broken PBX configuration.



  • I believe you. Currently working with FreePBX forum to resolve this.


Log in to reply