Hi
We are pulling our hair out slightly trying to get a SD-WAN deployment to play ball and have so far spent over 10 hours on the phone to support so far without them being able to explain why this traffic is doing what it is.
The scenario is a 9 site SD-WAN deployment, generated via Central, SIP trunks terminating in two sites on trunk switches for redundancy - below is a simplified schematic for a Head Office with trunk termination switch and a single Branch Office site with a phone at it. The telco is doing IP based authentication and requires the voice traffic to be broken out of the Head Office internet connection with an alias IP on the PortF1 WAN link.
The SIP side is basically working ok, we can establish and drop calls without issue; RTP media traffic from the branch site traverses the SD-WAN to the head office, is NAT'd using a SNAT rule to a specific public IP that the telco expects and the remote party can hear the outbound audio stream of the person at the BO site.
Where we are struggling is the inbound audio part; the XGS firewall at the HO can clearly understand that the traffic is the return data stream from the telco as it is matching the source and destination UDPs in reverse one assumes and you can see it is unNATing the traffic back to the IP of the phone at the BO site; we are then hitting a problem in that we can only then manage get the traffic back to the BO site if we put a static route in place for that sites subnet otherwise the firewall is turning the traffic around that has come in on WAN PortF1 and sending it back out onto the WAN with its internal 192.168.41.x address which clearly isn't routable and is presumably getting blackholed.
When we have the static route in play this works ok and we have bidirectional audio but clearly that is rather defeating the point of having the SD-WAN and it being able to failover between multiple xfrm VPN tunnels in the event of a WAN failure.
Green - telco media gateway IP
Yellow - WAN PortF1 IP
This is the SD-WAN route we have setup on the HO; it is top of the list of policies; there is a mirror one on the BO side that works ok; it was originally in the main Central deployed bundle of source/destination subnets but we have now separated it out so it is rule 1 so it is easier to check if traffic is actually hitting it as the "main" site to site rule is getting the traffic counters impacted by other site to site traffic.
This thread was automatically locked due to age.
