IKEV2 sound
Hi
I have a very odd problem, in that I am trying to pass voice call through an IKEV2 connection.
This works fine in IPSec and SSL, but when i try to do the same thing through IKEV2, I can receive an incoming call and the sound is fine, but when i make an outgoing call, there is no sound for me or the recipient
Anyone have any ideas?
0
Sign In to comment.
Answers
Hi @Tess
I'd suggest you enable logging on your IKEv2 Users policy (go into the policy, under properties, click logging, and check send log message.) After that's enabled, go into the traffic monitor, type in the IP of your workstation, and see if anything is coming up as denied.
If you post any logs here, please make sure any logs that have a username or external IP are edited to remove that info.
-James Carson
WatchGuard Customer Support
Thanks for your quick reply.
There are no denies from the incoming address.
The policies are already set to logging and i have set the IKEV2 logging level to information; the next level would be debug, which i haven't tried yet.
Debug logging will only give you connection information on the IKEv2 VPN establishing -- nothing on the traffic to/from once it's established.
If you haven't done so already, I'd suggest opening a case. The support team can take a deeper look at your logs.
-James Carson
WatchGuard Customer Support
Hi Tess,
This could be due to packet overheads and the MTU being set incorrectly resulting in fragmented packets.
I am currently working on a similar issue and use IkeV2 across all of my site branches and remote vpn users. It doesn't happen all the time, but by dropping the MTU on both sides we seem to have stabilised the issue (as in much fewer support calls).
I've been using this app to work out the highest common MTU between both points. https://www.iea-software.com/products/mtupath/
Give this a spin, im interested to hear the outcome.
Dave
For Windows, you can make registry changes to automatically identify the correct PMTU for a session.
The registry 2 settings are for:
Black hole detect
PMTU Discovery
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
EnablePMTUBHDetect dword:00000000
EnablePMTUDiscovery dword:00000000
I have a script, originally created by Alan Mercer a long time ago, on an earlier, long gone, forum.
I will try to post it - hoping that the stupid Markup feature of this forum does not mess it up.
Alan's PMTU script.
I use it as a .cmd file and run it as an admin
Run this in a CMD box as Administrator, with enable as the parameter, to apply the registry changes.
disable as the parameter, to remove the registry changes.
echo. >> pmtu.reg
if "%1" == "" (
echo ERROR: You must specify either "enable" or "disable" on the command line for this script to have any effect
goto cleanup
)
if /i disable == %1 (
echo Disabling PMTU >> %systemdrive%\pmtu.out
echo Disabling PMTU
REM Finish creating our reg file.
echo [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters] >> pmtu.reg
echo "EnablePMTUBHDetect"=dword:00000000 >> pmtu.reg
echo [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters] >> pmtu.reg
echo "EnablePMTUDiscovery"=dword:00000000 >> pmtu.reg
REM Call the reg file
regedit /s pmtu.reg >> %systemdrive%\pmtu.out
goto cleanup
) else (
if /i enable == %1 (
echo Enabling PMTU >> %systemdrive%\pmtu.out
echo Enabling PMTU
REM Finish creating our reg file.
echo [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters] >> pmtu.reg
echo "EnablePMTUBHDetect"=dword:00000001 >> pmtu.reg
echo [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters] >> pmtu.reg
echo "EnablePMTUDiscovery"=dword:00000001 >> pmtu.reg
REM Call the reg file
regedit /s pmtu.reg >> %systemdrive%\pmtu.out
goto cleanup
) else (
echo ERROR: You must specify either "enable" or "disable" on the command line for this
script to have any effect >> %systemdrive%\pmtu.out
goto cleanup
)
)
:cleanup
REM Delete the registry script
DEL pmtu.reg
echo Finished processing >> %systemdrive%\pmtu.out
echo. >> %systemdrive%\pmtu.out
Thanks Bruce, im going to give that one a spin
That sounds really interesting, i will see if i can give it a go. thanks
I am curious what the final resolution of this issue was (including the experience from others who posted on this thread)
@ibrown
For SIP calls, it's usually the SIP client putting the wrong IP address (there's an agent IP that the SIP server basically uses to send replies to -- if it doesn't appropriately figure out its correct IP, the server will often send the return audio to a place where it isn't wanted/needed and it's just dropped.)
Most phones use a process called STUN to do this.
SIP signaling is in plaintext, so you can use a program like wireshark to investigate your SIP traffic and see what it's actually sending for that IP in the SIP headers. If you need help doing that, I'd suggest opening a case, and one of our reps can help troubleshoot it.
-James Carson
WatchGuard Customer Support