Remote openVPN phone setup that need to exit on a different firewall
-
@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?
-
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
-
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.
-
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,
-
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.
-
@stephenw10 Hello, we are having similar issues with our OpenVPN inside of pfSense. Would you mind helping with this?
-
What exactly are you seeing happen? What are you expecting to see?
We need as much info here as possible to get to a diagnosis.
Steve
-
@stephenw10 Phase 1 is negotiating, but no phase 2. looks like the call is no longer exiting out the correct firewall (SonicWALL) Phone isn't registering (Cloud based CM) Phone must come in PFSense (in TUN mode) on Tunnel Address and route through interal LAN (phone VLAN) to Second Firewall and register in the cloud. Once registered all calls must maintain this pathway without exiting the PFSense for call (needed to record calls) Note KevinM and I are with the same company
-
When you say Phase 1 and 2 you mean of the VoIP connection, not IPSec?
Are you seeing the traffic from the phone leaving the pfSense WAN directly rather than the interface to reach the Sonicwall? The states look correct?
Yes so we are clear the path here is:
Yealink Phone --<openvpn tun>-- [WAN] pfSense [LAN]------- Sonicwall---Cloud VoIP provider
And the phone(s) are at some remote location.
Steve
-
@stephenw10 Phase 1 n 2 for VoIP vis Open VPN. Doesn’t appear to be exiting out PFSence, but not seeing exit out SW either
-
@stephenw10 Stephen,
What we need to happen is a VoIP Phones come into PFSense (PF) on their VLAN, which is then routed to the VoIP VLAN and exit our a SonicWALL (SW) to the Cloud to register. Once registered the phone traffic needs to use this routing for the entire call session on outbound calls and inbound calls. This is needed because our call recorder Server is internal and is required for compliance. The actual calls shouldn't go out the PF WAN interface to the CM.
-
@stephenw10 You indicated the OpenVPN is using the default gateway (WAN) and that we need to change that to point to the gateway for the LAN which is the address on the SW. Where do we go to make that change?
Thanks,
-
@gpeting said in Remote openVPN phone setup that need to exit on a different firewall:
VoIP Phones come into PFSense (PF) on their VLAN, which is then routed to the VoIP VLAN and exit our a SonicWALL (SW) to the Cloud to register
Where is the OpenVPN in that?
I assumed it was using the OpenVPN client in the Yealink phone connecting to an OpenVPN server running in pfSense? If so there's no VLAN involved there.Steve
-
@stephenw10 You are correct the client is on the Yealink Phones and the OpenVPN server is configured on the PF. The phones are getting a different IP Address from the LAN side of the PF. The phones are routing from their network into the VoIP network (PF LAN) and need to exit out the SW Gateway on the VoIP LAN. The SW is .1 and the PF is .2 on their respective LAN interface.
-
Ok. So I assume the phones are connecting to the OpenVPN server as expected and getting an IP in the OpenVPN tunnel network? The OpenVPN status page shows the phones connected?
What I expect then is to see a policy routing rule on the assigned OpenCPN server interface to send all traffic arriving from the phones via the LAN side gateway, which I expect to be the Sonicwall.
The default route for pfSense would still be via it's WAN so encrypted traffic to the phones goes that way. Is that a separate connection? A different public IP than the Sonicwall uses?
So look at the state table. You should see VoIP traffic (SIP and RTP) arriving from the phones on the assigned openvpn interface and then leaving on the LAN interface and no NAT happening. You should not see and VoIP states on the WAN.
Steve
