asterisk users - Nov 2016 - Suddenly getting lots of "Unable to send packet: Address Family mismatch between source/destination" but ONLY on 1 of 2 VPSs in same datacentre.

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

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!


On 4 November 2016 at 21:31, Jonathan H <lardconcepts at gmail.com> wrote:
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20161105/e390a84d/attachment.html>

Hi Jonathan,

Am 05.11.2016 um 14:08 schrieb Jonathan H:
> 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??!
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 <nameofyourinterface>

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20161105/3f4d5c72/attachment.pgp>