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?

Answers

  • james.carsonjames.carson Moderator, WatchGuard Representative

    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.

  • james.carsonjames.carson Moderator, WatchGuard Representative

    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.

  • edited October 2020

    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 :smile:

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

  • james.carsonjames.carson Moderator, WatchGuard Representative

    @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

Sign In to comment.