Hello, I’m new to Peplink and SpeedFusion, but have found it fairly straightforward. I’m looking to route all my voice calls through Speedfusion to get WAN smoothing, failover, etc (I have a Spectrum cable connection and Starlink joined together currently). I have two Vonage systems and found it easy to route them using their Mac address and also a rule to route all VOIP protocols to SpeedFusion, and it works fine, when I use either device I see active status in the Speedfusion tunnel, and they are crystal clear.
I also have a couple Samsung S-series phones that are on the Verizon network and enabled to do wifi calling, which is what I use here in my remote location. I can’t seem to find anything that will route the Verizon Wifi calls to Speedfusion. I do not want to run all those phones apps through Speedfusion, so doing it the device level isn’t an option. I did find a suggestion online to use a rule to route all traffic going to domains sg.vzwfemto.com and wo.vzwwo.com as those are supposedly what Verizon wifi calling connects to, but I put in those rules and wifi calls still do not go to Speedfusion when watching the status monitor.
… so, I’m still searching for a way to set a rule to route all Verizon Wifi calls to Speedfusion? Any suggestions appreciated!
WiFi calling regardless of the carrier involved generally is done inside a VPN from the phone to the carriers infrastructure.
A quick search on Google suggests there are also two domains used as part of VZWs implementation, so some outbound rules to match those domains might do the job on its own:
Source = ANY
Destination = Domain Name
Domain = sg.vzwfemto.com & wo.wzwwo.com
Protocol = ANY
Algorithm = Priority - set your SF VPN as the only thing in the list, tick terminate on recovery and fail through so the traffic can still have a chance of going out if the SF tunnel is down.
Domain rules can sometimes be a bit hit and miss, if that doesn’t do the job then try two outbound policy rules to match IPSEC/NAT-T traffic should do the job:
Source = ANY
Destination = ANY
Protocol = UDP
Port = 500 & 4500
Algorithm = Priority - set your SF VPN as the only thing in the list, tick terminate on recovery and fail through so the traffic can still have a chance of going out if the SF tunnel is down.
In the case of the IPSEC policy you may want to consider setting a couple of static IPs on your phones via DHCP and instead of source = any specify the IPs you give them, that way other IPSEC VPN traffic will not get directed out the SF tunnel.
To see if it is working put your phone into flight mode, go to Status > Active Sessions > Search, put your samsung IP in as the source and see where it is sending traffic.
1 Like
Hi, thank you for the suggestions. Unfortunately none of these seem to work. I had already tried using those two domain names with no luck. I created the two new outbound policy rules for UPD port 500 and 4500 and they don’t seem to trigger for some reason. I have my phone set to static IP 192.168.0.103 and I can see in active sessions the UDP to port 4500 when I’m making a wifil call, but it is still going to my primary Spectrum line, not the SF VPN (I tried setting source to both ANY and the phone’s IP address and still get the same result). Screen shots attached of the 4500 rule and the active session results for reference. Any other suggestions appreciated!
Try with enforced instead of priority for now.
Also can you share a screenshot of your entire outbound policy rules - they are processed from top to bottom down the list and the first rule to match for any given packet will apply so it could be that you’re hitting another rule first.
Hi, I did set to enforced and the traffic is still going on the Spectrum link rather than the SFC. Here is the requesed screen shot of all rules and also the status monitor. Thank you!
Try placing them above the grey box that says “PepVPN / OSPF / BGP” etc.
If that isn’t letting you do that click the blue question mark and enable expert mode, depending on the model of your Peplink expert mode may also just be an option on that screen below all the rules.
Suspect this is partly due to SFC and how the rules it uses are slightly obfuscated in this table when they are configured elsewhere - for example you said you had routed VoIP traffic to SFC, but there are no policy rules for it there.
2 Likes
I moved the rules for UDP ports 500 and 4500 above the grey box that says “PepVPN / OSPF / BGP” and that worked! Thanks for your help!
