A Wireguard VPN was created between two sites, using two routerboards.
There are telephones on the local site; on the remote site a 3CX SBC used as a proxy for the phones; 3CX PBX is in the Cloud.
Previously the two sites were connected with SSTP VPN and there were no problems.
Now, once replaced SSTP with Wireguard, there is a one-way audio problem (it only goes from the local site to the web, not vice versa).
I already tried enabling STUN, disabling ALG SIP.
All others application throught VPN are correctly running (web service, RDP, mail, ect.), I have problem with RTP…
Set up SSTP between the two routerboards and run the VOIP through that vice wireguard??
Its quick and easy to set this up using mchap2 no certificates.
Just for giggles on the routerboard that is client for handshake. set up this mangle rule which helps if there are any MTU issues…
If it was a problem it should affect more than just VOIP so a long shot. /ip firewall mangle
add action=change-mss chain=forward comment=“Clamp MSS to PMTU for Outgoing packets” new-mss=clamp-to-pmtu out-interface=wireguard-interface-name passthrough=yes protocol=tcp tcp-flags=syn
The only idea I’ve got is to sniff the same call simultaneously at both Mikrotiks to see whether it’s the phone asking the 3CX via SDP to send the RTP to a wrong public address it has detected using STUN or some firewall/routing issue on one of the Mikrotiks.
Before reading the configurations, I’d rather see the sniffing results first. It should show you whether the RTP arrives from the 3CX to the router that is closer to it.
If it does, the RTP may get lost when forwarded by that router to the Wireguard tunnel, or when passing through the tunnel, or when being forwarded by the router next to the phone from the Wireguard tunnel to the LAN.
If the RTP doesn’t reach your network at all, it’s a matter of what destination the phone asks the 3CX to send the RTP to and how much the 3CX trusts that information, and whether the RTP from the phone towards the 3CX gets NATed properly (normally it should NOT be NATed on the router closer to the phone and it should be src-nated on the router closer to the 3CX).
Interesting, what was the sniffer filter on “local”? Because on “remote” I can see the SIP signaling from the phone at 192.168.66.22 to come from 172.31.192.2, which suggests that there is a src-nat on the “local”, but in the “local” capture, the INVITE is only seen to go from 192.168.66.22 to 192.168.59.95, the src-nated version of the same packet is missing there. Did you exclude the Wireguard tunnel from the sniffing?
Anyway, the SDP that arrives to the 3cx from the phone at 192.168.66.22 says “send me the media to 192.168.66.22”, so does the 3cx itself have a route to 192.168.66.22 via the “remote”, and does the “remote” have a route to 192.168.66.22 via the Wireguard tunnel? Does 192.168.66.22 fit into some prefix in the allowed-address list for the Wireguard peer representing “remote” on “local”?
It was filter with by IP 192.168.59.95 (remote SBC), with no other exclusions.
Ok, found a missing nat, but this not resolved problem…
Now I must move this test to other site that has same problem.
This link to new capture: audio on remote RB is OK (here there’s the phone1), in central RB is OK…but when I call phone 1 I have one way audio (phone1 can listen me, but I can’t heard what phone1 say…). May be I can’t read it correctly? https://drive.google.com/file/d/1U3sPwaz7szGs0AKoelW9HfktjbyG6fXN/view?usp=sharing
It’s a mess this time. The single call in “central” and “remote” captures is not the same one, and the capture from “3cx” sends the SIP messages between two local processes across 127.0.0.1.
To be able to say something, I need a capture of the same call from the router to which the phone is connected (which, I suppose, is one end of the Wireguard tunnel), from the router that is the other end of the Wireguard tunnel, and from the outer interface of the SBC (the IP to which the phones register). And pcap file names that clearly indicate which one is which.
Check if your Wireguard configuration is correctly routing RTP traffic between the sites. You might need to update your routing tables or firewall rules to ensure RTP packets can flow in both directions. Also, make sure your firewall settings on the routerboards aren’t blocking incoming RTP traffic from the remote site to the local site. Sometimes, Wireguard can be more restrictive by default compared to SSTP.
I don’t get it. The only call in “remote” is at 12:00:02, from 501 to 1601, Call-ID 7-44Ub0OL5NSjkjmcN94jA.. The only call in “central” is at 11:52:30, from 1270 to 1270, Call-ID d3Rz1_aeZjjXSCHjjjVcPA.. . How are these two related? The time spans of the captures do not even overlap …
Draw a network diagram, indicate how the tunnels are set up, check that the times are correct on all routers, and capture at all places simultaneously.
Wireguard has serious limitations. Wireguard only works well in ads. Most softphone programs VOIP don’t work in Wireguard. SIP isn’t working properly. Waste of time Wireguard is not suitable for SIP. Please remember that Wireguard only works on layer 3 and needs routing everywhere. I did many tests and gave up.
