IAX2 Getting Stuck

I have a server that had been operating for a few years now with IAX2 trunks to several other servers. Since yesterday all IAX2 trunks now say UNREACHABLE. No configuration changes have been made and no upgrades have been done. The server is running 11.16.0 (yes, we are planning upgrades but lets solve this first). The server has a USB
ethernet adapter that got disconnected yesterday by accident and since it was reconnected we started having the problem. We have rebooted many times and even replaced the USB adapter but still the same issue, and the USB adapter is not the main ethernet link to the local network, it is just for a link to a provider. So far the only thing different is that the receive queue for port 4569 is not zero like all the other servers:

udp 128760 0 0.0.0.0:4569 0.0.0.0:*

Basically all packets for IAX2 are getting stuck in the queue. Any suggestions?

We have already tried that. One of the servers that has an IAX
trunk to this server is on the same local network so that eliminates any firewall/router in the way. We disabled iptables just in case too.

1- No changes to device names. eth0 is the main link to the network, eth1 (also internal) goes to a SIP provider and eth2 (the USB adapter)
goes to another SIP provider. All IAX trunks use eth0

2- ifconfig gives the proper IP and netmask for all interfaces

3- We do not specify bindaddr or bindport in the config file as the default is to bind to 0.0.0.0

4- We had to make new SIP trunks to replace the IAX2 trunks to all servers. The SIP trunk is working with no problems. Except for two SIP
links to PSTN all internal extensions use the same network interface.

Can it happen that the routes lead the traffic through another interface?
Did you try a packet capture with tcpdump? Do the packets really leave the usb adapter? Can asymmetric routing be in effect?
Maybe there were some static routes that disappeared when the adapter was unplugged…

The new SIP trunks are replacing the IAX2 trunks to our other Asterisk servers and use exactly the same network paths, that is why I
know it is not a network infrastructure issue. We did turn on IAX debug and we only se the server trying to poke the other servers but there is not response or any incoming traffic.

Hmmm.. So if you are sure that the poke packets leave the network interface
(I would still check with tcpdump as well, maybe a firewall issue?) then it makes sense to check the other side to make sure the poke packets reach other servers. I mean with tcpdump you may see if there are incoming packets from your peers on the interface. If there are, then they are dropped or ignored by your servers. If no, then it’s better to check the other side. you may try smth like ‘tcpdump -npi host and port 4569′
Do you have a firewall configured on this server?