Remote openVPN phone setup that need to exit on a different firewall



  • Hi All,

    I have an unusual situation where I have remote users' phones hitting a PFSense firewall and are moved to the VoIP (LAN) network. The call manager is cloud based and need the remote phones to register from another firewall. In other words the call setup comes in the PFS and is moved to the main firewall and the registration happens from the other firewll. This is done so the call can be recorded with an onsite call recorder. The VPN connection seems to work fine but can't register causing the phones to reboot and then it goes out the WAN side of the PFS and the traffic moves off the VoIP network and isn't recorded. I've looked at routing and NATing but see nowhere I can force the traffic to exit via the other firewall based on sourse IP. I have thought about pointing the PFS LAN default gateway to the LAN side of the other firewall (both LAN ports are on the VoIP network). Does anyone have any thoughts on this. Thanks



  • @gpeting Here is the configuration I've put into place. I see the VPN tunnel up and the first IP Address in the pool assigned but the phone is unable to ping 10.105.0.1 nor does the phone register.

    OpenVPN server

    General Information
    Disabled - Unchecked
    Server Mode - Remote Access (SSL/TLS)
    Protocol – UDP on IPv4 only
    Device Mode – tap-Layer 2 Tap Mode
    Interface - WAN
    Port - 1194
    Description – OpenVPN Remote VoIP Users

    Cryptographic Settings
    TLS Configuration – Use a TLS Key (2048 bit)
    TLS Key – 2048 bit OpenVPN static key
    TLS Key Usage Mode – TLS Authentication
    TLS Keyidr direction – Use default direction
    Peer Certificate Authority – NOLA CA
    Peer Certificate Revocation List – None defined
    Server Certificate – NOLA Yealink OVPN (Server: Yes, CA: NOLA CA, In Use
    DH Parameter Length – 1024
    ECHC Curve – Use Default
    Encryption algorithm - AES-256-CBC (256-bit block)
    Enable NCP – Checked
    NCP Algorithms – AES-128-GCM
    Auth degest algorithm – SHA 1 (160-bit)
    Hardware Crypto – No Hardware Crypto Acceleration
    Certificate Depth - One (Client+Server)

    Tunnel Settings
    Ipv4 Tunnel Network - Blank
    Ipv6 Tunnel Network - Blank
    Bridge DHCP - Checked
    Bridge Interface – LAN
    Bridge Route Gateway – Unchecked
    Server Bridge DHCP Start – 10.105.0.200
    Server Bridge DHCP End – 10.105.0.254
    Redirect IPv4 Gateway – Checked
    Redirect IPv6 Gateway - Unchecked
    IPv4 Local Network – Not shown when Redirect IPv4 Gateway is selected (10.105.0.0./24 if unselected)
    IPv6 Local Network - Blank
    Concurrent connections - 50
    Compression – Omit Preference (Use OpenVPN Default)
    Push Compression - Unchecked
    Type-of-Service - Unchecked
    Inter-client communication - Unchecked
    Duplicate Connections – Unchecked

    Client Settings
    Dynamic IP - Checked

    Ping Settings
    Inactive – 0
    Ping method – Keepalive – User keepalive helper to define ping configuration
    Interval – 10
    Timeout – 60

    Advanced Client Settings
    DNS Default Domain - Unchecked
    DNS Server 1 – 10.105.0.1 (LAN Gateway of SonicWALL FW)
    DNS Server 2 – 66.28.0.45
    DNS Server 3 – 66.28.0.61
    DNS Server 4 - Blank
    Block Outside DNS – Unchecked
    Force DNS cache update – Unchecked
    NTP Server enable – Unchecked
    NetBIOS enable – Unchecked

    Advanced Configuration
    Custom Options – None specified
    UDP Fast I/O – Unchecked
    Exit Notify – Disabled
    Send/Receive Buffer – Default
    Gateway creation – Ipv4 only
    Verbosity level – 3 (recommended)



  • This post is deleted!


  • [0_1588250229805_VoIP VLAN Problem.pdf](Uploading 100%) VoIP VLAN Topology.PNG



  • Phones need to go our the SonicWALL to register. The voice traffic can't hairpin at the PFSense but needs to exit the SonicWALL so it will pass the Access Switch where the call recorder is connected.


  • Banned

    @gpeting Have you downloaded Hotspotshield vpn app? I saw here some recommendations, tried it. I think you have already guessed that it doesn't work well. I chose American configuration, the only working one in Europe for free. But it works disgustingly. On all my devices, phone, tablet. Any ideas?



  • Howard, Thanks for the reply, interesting VPN App. Unfortunately the VPN is imbedded on a VoIP phone and is independent of the browser and heads to a different firewall. Due to how the network is configured I can't piggy back the phone on the PC VPN. Also the phones I am using can't be directly configured, they are configured using a .tar file. The Problem I'm having is I can move traffic the way I want using TUN mode but need TAR to preserver the ports (can't get TAR to work) and I see no way to force a 1:1 static NAT for multiple remote locations. I can set up NAT but it is dynamic only. Does anyone know if 1:1 static Inbound NAT can be configured?


  • Netgate Administrator

    You should run in TUN mode.

    Policy route the incoming VoIP traffic from the phones on the OpenVPN interface to the Sonicwall.

    Add a route on the Sonicwall back to the OpenVPN tunnel subnet.

    No NAT needed, no problem with ports.

    Steve


  • Banned

    This post is deleted!


  • @stephenw10 Steve, Thanks for the post, we are currently using TUN mode and the traffic is moving the way we want during call registration. When the Call Manager hands off the call for point to point is were the issue is coming in. The recorder we are using needs a RTP port in the range of 39xxx to listen to the call and a static IP Address on the phone to map the call to the employee. We see the DHCP assigned address on the tunnel setup and registration (trying to figure a way to get the phones to take a static IP without geting overwritten by the .tar file), but it looks like the call then NATs to the LAN IP on the PFSense and changes the RTP ports. It is also possible the point to point is hairpinning out the WAN interface, we will be testing to see if this is the case. Any advice would be greatly appreciated. Also we tried TAP mode but could never access the LAN, not sure if there was something missing in the config though.


  • Netgate Administrator

    If it's NATing to the LAN interface that's a bad outbound NAT setup. If your outbund NAT is still is automatic mode then you have a gateway defined on the LAN interface directly which is wrong. pfSense assumes it to be a WAN in auto mode if you do that. Remove the gateway from the LAN interface config. It can exist as a gateway in the LAN subnet so you can route to it.

    Steve





  • @stephenw10 I included my LAN interface configuration. The gateway is the inside address of the other firewall. Where would I go to turn off the automatic mode on the NAT? Thanks,


  • Netgate Administrator

    You can do that in Firewall > NAT > Outbound. Switch to manual and remove the rules on LAN.

    But the 'correct' solution here is to remove the gateway from Interfaces > LAN and add it back in System > Routing > Gateways.

    Steve



  • @stephenw10 Steve, The solution worked. We successfully recored a call yesterday. Thank you very much for your help.


Log in to reply