Jonathan H
2016-Nov-04 21:31 UTC
[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.
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
Jonathan H
2016-Nov-05 13:08 UTC
[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.
I resolved it when I read this: asterisk-support.ru/question/61578/asterisk-v13-unable-to-send-packet-address-family and then followed this 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: <lists.digium.com/pipermail/asterisk-users/attachments/20161105/e390a84d/attachment.html>
Max Grobecker
2016-Nov-05 14:15 UTC
[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.
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 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: <lists.digium.com/pipermail/asterisk-users/attachments/20161105/3f4d5c72/attachment.pgp>