[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.

[Max Grobecker]

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>