As SpeedFusion Connect does not offer stable public IPs, I am looking at using FusionHub on a cloud provider (GCP in this case) as an endpoint for a small VoIP SIP trunk.
I’m having trouble wrapping my head around the feature/UI differences on the FusionHub side and the required routing settings to forward the SIP signaling both directions, to/from a SIP SBC.
SIP does not get along with NAT, and there are many forum posts mentioning the IP Forwarding routing mode, SIP (ALG) Compatibility, SpeedFusion NAT (off), and outbound policies. I’ve tried a slew of combinations, but I’m still having trouble finding the right routing for SIP signaling to pass in both directions, particularly outbound. While common for cloud providers, the public IP being mapped to the private IP for the FusionHub WAN is not helping my understanding either.
The first thing I ever did with a Peplink was run VoIP over it and from then till now I still find fixing VoIP traffic issues horrible…
The first thing I would say is that you’re making things harder for yourself using GCP because you are adding double NAT at the Fusionhub since the Fusionhub does not have a public IP itself. Vultr, OVH, Hetzner and others will be easier to use.
That said, the theory is a SIP session sent to 30.0.0.1 will get 1:1 NAT translated to 10.64.0.1 and then what you want is to port forward (NAT) from the WAN of the Fusionhub to the LAN IP of the remote SBC 10.0.0.2.
Those ports will be your SIP signalling and then your RTP / media ports.
Speedfusion VPN lets that layer 3 non NAT traffic routing work between the Fusionhub and your SBC.
As it turns out, it was indeed much simpler that I initially thought, at least on the Peplink routing side.
As you mentioned, from a clean FusionHub setup, all that was needed was:
FusionHub: Forward SIP signalling port (5060) to SBC 10.0.0.2
I did also create an outbound policy on the local Peplink to be able to test ensure the SBC traffic was leaving via the tunnel. The GCP 1:1 NAT works (more or less) transparently as advertised.
If I manually set the public IP for the outgoing SIP packets (headers/SDP) on my SBC I can indeed get everything working, which confirms routing is all correct.
I did notice on the local Peplink, SIP Standard Mode (ALG) does not appear to consider the SpeedFusion VPN tunnel a WAN, and does not rewrite SIP packets going out the tunnel. Which I suppose makes sense if the tunnel route is technically via local IPs.
I’m curious if there is any way around this. Ideally there would be SIP ALG capability on the FusionHub side, but this setup doesn’t exactly seem like an intended use-case.
I don’t think there is a way to advertise the FusionHub public IP (when on a proper hosting service) to the local end of the SpeedFusion VPN(?) (Layer 2?) If the next hop from the local Peplink is the public IP, SIP ALG would, in theory, do its job (but I don’t actually know if that’s true, or if tunnels are just excluded altogether).
In my case, I think I can do some trickery on my SBC to rewrite the original outgoing packets with the correct public IPs, but a NAT capable solution would be really nice. Not that I expect anything involving VoIP to be nice.
