VoIP over Wireguard Vpn: one way audio problem. (2024)

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...

Ideas?

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

Thanks @anav for your reply.

I tried to insert code you posted, but it don't resolve the issue, I have one-way audio.

This is getting annoying... I cheched routing, NAT, but in WIREGUARD it has always one-way audio problem.

I need an help or more ideas!!!
Thanks!!!!!!

I need an help or more ides!!!
Thanks!!!!!!

Post your config , mask sensitive info .
There will be rain of ideas ...

Attached configuration of both RB, if can help....

Thanks!!!!!!!!!!!!

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).

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.

Attached pcap files, thanks!!!!

Attached pcap files, thanks!!!!

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"?

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/1U3sPwa ... sp=sharing

It was filter with by IP 192.168.59.95 (remote SBC), with no other exclusions.

The only explanation I can imagine is that there is a bug in sniffing on Wireguard interface.

Ok, found a missing nat, but this not resolved problem...

What I saw was one NAT too many, not a missing one...

https://drive.google.com/file/d/1U3sPwa ... sp=sharing

It asks me to ask for access, was it not possible to attach it here like the previous time?

It was filter with by IP 192.168.59.95 (remote SBC), with no other exclusions.

The only explanation I can imagine is that there is a bug in sniffing on Wireguard interface.

Ok, found a missing nat, but this not resolved problem...

What I saw was one NAT too many, not a missing one...

https://drive.google.com/file/d/1U3sPwa ... sp=sharing

It asks me to ask for access, was it not possible to attach it here like the previous time?

File it's too large for forum, you can download here:
https://we.tl/t-qtoDf89Wv5

Thanks!

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.

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.

Thanks for you support!!

Call is the same, the captures was made at same time at RB on both side of Wireguard tunnel and 3CX pbx.
Now I can't capture traffic at SBC.

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.

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.

That's the call in remote: