Idiot ISP port blocking fix

After spending days trying to figure out why one of my PEPwave MAX-BR-1 units would always have one IP phone not able to register, I finally figured out that it is the ISP blocking or consuming traffic to port 1025

PEPwave running the PPOE, so public IP is on it.
Behind the PEPwave are five Yealink IP phones. They are registering to a softswitch cluster on a public IP in our data center.
We are not using VPN.

Same setup at many other locations with no issues.

Problem at this location is four of the five phones register, one fails. If I reboot the PEPwave it may be the same one, or it may switch. If I plug in a sixth phone then five will register and one fail.
The registration does reach the hosted PBX. The 401 authenticate response does not reach the phone.
I thought that this was a weird NAT problem in the PEPwave. With help from peplink support I learned how to do packet captures in the PEPwave, and found that that response was not reaching the PEPwave, but I confirmed that t was leaving the PBX, and leaving the border router in the data center.
As I said the words “Strange. It does have the correct NAT address for the phone. The public IP at port 1025” to Ron from Peplink, I suddenly realized that as the problem moved form phone to phone after reboots, it is ALWAYS port 1025. And I realized that the problem is frontier communications eating the packets, probably because they are using port 1025 for something else.
So - I am sure I am not the only person with this problem.
FYI - the frontier DSL modem is n bridge mode, so it should not be grabbing any packets, but with it or something upstream from it is doing so. Ron said that they have seen this problem with other customers, and knew it was specific to specific ISPs, but had not pinned it down to being a specific port. Just that one phone would not register, and if you switched ISPs the problem went away.

Enhancement request:
Ability to change the port range used for NAT. Instead of SIP using 5060 for first device, then 1024, 1025 etc, be able to specify a different starting port. This should be an easy enhancement and will resolve a problem that many people have probably had.

John Scully


Hi John,

Thank you for your sharing! Engineering team is looking into this now.

You have provided valuable analysis to us. This makes perfect sense. Thanks for your effort!

1 Like

Any update on this?
I can confirm this is indeed an issue on Frontier, for now we just create a port forward for port 1025 to a ip not in use so that port does not get used by nat.

This was in our roadmap. However, no ETA at the moment. Have you complained to Frontier on this?