Suddenly Getting Lots Of “Unable To Send Packet: Address Family Mismatch Between Source/destination” But ONLY On 1 Of 2 VPSs In Same Datacentre.

Home » Asterisk Users » Suddenly Getting Lots Of “Unable To Send Packet: Address Family Mismatch Between Source/destination” But ONLY On 1 Of 2 VPSs In Same Datacentre.
Asterisk Users 3 Comments

Two VPSs. Identical setups with the exception of the extension.

Same version of everything, Asterisk 14.1, Ubuntu 16.10, same firewall rules and so on – box 2 was cloned from box 1.

Both VPSs run in the same datacentre.

Suddenly, after weeks of OK, I’m getting lots of this on ONE box only:

[Nov 4 21:23:04] NOTICE[1468]: res_hep.c:466 hep_queue_cb: Unable to send packet: Address Family mismatch between source/destination
[Nov 4 21:23:04] NOTICE[1468]: res_hep.c:466 hep_queue_cb: Unable to send packet: Address Family mismatch between source/destination

Googling this brings up something about IPv6, but my VPS is not IPv6
enabled, and nor is my ITSP, who can’t think of why this is happening.

It doesn’t appear to be adversely affecting call quality, but it’s making the console a bit busy. I know I can hide it, but I’d be interested to know if there’s anything I can do to diagnose WHY this is happening.

Thanks

3 thoughts on - Suddenly Getting Lots Of “Unable To Send Packet: Address Family Mismatch Between Source/destination” But ONLY On 1 Of 2 VPSs In Same Datacentre.

  • I resolved it when I read this:
    http://asterisk-support.ru/question/61578/asterisk-v13-unable-to-send-packet-address-family/
    and then followed this https://community.rackspace.com/products/f/25/t/5110
    to explicitly prefer IPv4 over IPv6.

    What I don’t understand is that while Ubuntu has IPv6 of course, the VPS
    host is set to V6 disabled. and as far as I am aware, and my ITSP doesn’t have IPv6, so I just can’t figure out why two IPv4 systems are getting IPv6
    “pollution” as it were. And why now??!

    Anyway, that’s what fixed it for me. Thanks!

  • –eRST8akE0Ddt0Kmg11e0vSphuHLgB3aSm Content-Type: text/plain; charset=windows-1252
    Content-Transfer-Encoding: quoted-printable

    Hi Jonathan,

    Am 05.11.2016 um 14:08 schrieb Jonathan H:

    That *MAY* be caused by a rogue IPv6 Routing Advertisement in the network where your vServer is located. If you have a global IPv6 address assigned to your interface with the flag “dynamic” you got this address via autonomous addressing provided by routing advertisement. To verify, look at the output of:

    sudo ip -6 addr show dev

    You’ll find one or more lines starting with “inet6”, followed by the assigned address and at the end of the line the flags;
    For example “inet6 2003:……:1234/64 scope global dynamic” – this would be a dynamically assigned address.

    Also, doing a

    sudo ip -6 route show default

    Will bring more clarity, if you get a route entry like this:
    “default via fe80::230:88ff:fe04:d dev ppp0 proto kernel metric 1024 expires 1539sec hoplimit 64”

    The “expires” information indicates this route has been learned by RA. If you have no route entry this means you might have no IPv6 connectivity at all. If there is a route entry but without “expires” information the route has been added manually.

    If you have a global IPv6 address assigned to your interface, please check if it belongs to your providers network. An easy way to check this is via https://stat.ripe.net (they use all RIR databases, so you’ll find information about all regions).

    In either way: Your provider should be worried about this. Either there is a way for other customers to advertise (malicious) IPv6 routing information into the network that affects other customers or your provider simply does not know that he is actively announcing and routing IPv6 or configuring customer’s vServers with IPv6.

    If it’s a malicious or at least unknown advertisement, you definitely should deactivate the use of RA in your sysctl by setting in sysctl.conf:

    net.ipv6.conf.all.accept_ra=0
    net.ipv6.conf.default.accept_ra=0

    Then, do a “sysctl -p” and manually remove the already assigned route.

    The reason why you should not ignore this is:
    When you get IPv6 routes via rogue advertisements and your servers is sending IPv6 traffic through the attackers server, he will be able to read your traffic. And – for unencrypted VoIP traffic – he can simply see only all the numbers you dialed, seeing what DTMF keys were pressed and finally listen to the voice stream.

    So – this is definetely worth to investigate and to get your ITSP have a look at it. There are many ways to stop other customers from doing this (maybe this happens accidently). If you have further questions you might contact me off-list – since this is something that does not really fit in the asterisk list 😉

    Max

    –eRST8akE0Ddt0Kmg11e0vSphuHLgB3aSm

  • Just to say “thank you” on the list, and to confirm that the output of the command you suggested are as follows:

    # ip -6 addr show dev eth0
    2: eth0: mtu 1500 state UP qlen 1000
    inet6 fe80::601:ddff:fea2:dXX1/64 scope link
    valid_lft forever preferred_lft forever

    # ip -6 addr show dev eth1
    3: eth1: mtu 1500 state UP qlen 1000
    inet6 fe80::601:ddff:fea2:dXX2/64 scope link
    valid_lft forever preferred_lft forever

    ip -6 route show default is blank

    So from what I understand, this should be OK? I’ll dig a little deeper, drop the host an email, and contact you privately if needed.

    Thanks again.