Warning for users of Cisco SMB RV082 V3

[robmurphy]

The latest firmware 4.1.1.01-sp.bin breaks SIP calls. The Router rejects various SIP messages
on the WAN side. I have reported this and am looking through the trace more closely at present.

The problems were noticed after upgrading the router firmware. Reloading the previous firmware fixed the problems.

Rob

 

[robmurphy]

After checking the Ethernet trace I can see that each time one of the SIP phones registers NAT on the router is setting up a different port on the public IP address. This effectively means the IP phones public address (i.e. the IP and port used) changes each time the phone registers. The IP phones are setup with short registration times, so the port is changing during the call or during call setup.

The firmware used is the same for the RV042 V3 and the RV016 V3, so the fault will probably affect these routers as well.

Rob.

 

[spidey07]

Do you have SIP fixup configured?

 

[robmurphy]

A quick google shows the SIP fixup applies to the PIX firewalls. I have not seen this option on the RV082 V3.

Rob.

 

[spidey07]

SIP and NAT don't play nice together which is what you're seeing. There should be an option to allow SIP to traverse the address translation.

 

[robmurphy]

I know SIP and NAT do not play nicely.

The only way to "fix" the ports used for SIP is to use port forwarding. This usually means having to use static IPs for the IP phones. It may be possible using PAT to get round this by having an external port on the public IP for each of the private IPs within the DHCP pool. If I get time I may try this.

One of the reasons for the very short registration period is to keep the UDP NAT session open.

The exchange used is Asterix based, and normally uses the SIP Notify message as the NAT keep alive messages. This was not working as the PBX was always sending the reply back to port 5060 on the public IP address.

As the Notify messages were not getting a response from the PBX the phones were registering every 30 seconds, instead of the 300 seconds they were set for. Most of the phones worked OK with this setup.

The setup was changed to use a registration of less than 2 minutes, and not to use the SIP notify messages. This has worked fine for several months now and has reduced signalling traffic by over 60%.

This new version of firmware breaks SIP as it sets up a new NAT mapping for each registration. As the registration period is less than 2 minutes it means the port used changes during the call or in call setup. I have not seen a router do this before. The NAT mapping that was being used had not been re-used as until the registration it was allocated to the IP phone.

The basic fact is that Cisco have released a firmware that breaks SIP, and possibly some other protocols as well.

Cisco may not except this as a fault. With the usual 60 minute registration period for IP phones the fault may not reproduce in their LAB, or they may not see it as a fault.

I have supplied a trace of the problems and explained it from my point of view. Cisco have opened a case for this and I will find out next week if they accept it as a fault.

I posted the problem here just so that anyone with SIP phones connected through one of these routers is aware they are likely to get problems if they use this firmware.

If you downgrade the firmware you loose all your config, so make sure you have a backup of it before you try an upgrade, and do a factory reset after a firmware downgrade.

Rob.

 

[robmurphy]

I tried using port forwarding and PAT so that port 5080 was set to map to port 5060 on one of the IPs.

If an incoming connection comes in on port 5080 of the public IP the packet is forwarded to port 5060 on the private IP, and the response is sent from port 5060 on the private IP, and then port 5080 on the public IP

When the IP phone sends a request from port 5060 it does not go out on port 5080 of the public IP however.

For SIP its the connections coming from the phone that are important as that is what the PBXs use to decide what port to send the response on, or messages to initiate for a call to that phone.

Rob

 

[spidey07]

Sounds like PAT is doing what it's supposed to do. You need a sip fixup. There are many protocols that don't like NAT/pat. The router needs to know you want to treat those conversations differently based on l7 application or l4 port.

 

[drebo]

Disable the SIP ALG. They never work properly, anyway.

 

[robmurphy]

There is no option to disable the SIP ALG.

As said before, the previous firmwares used with these routers worked OK.

You do have to look at what is happening with SIP. Changing the port on the public IP on every registration would cause problems with or without a SIP ALG.

If you check the traces for a call using an Asterix based PBX you can see the PBX does not send any RTP until the SIP endpoint starts sending it. This establishes a NAT mapping for the RTP. This is one of the ways Asterix works around NAT.

The main problem is incoming calls and call transfers as for this the PBX initiates the signalling and uses the IP and port number from the last registration. If that NAT mapping has been lost incoming calls and call transfers do not work.

As said before this firmware breaks SIP, and according to the release notes it was supposed to fix some SIP problems.

Rob.

 

[spidey07]

Cisco tac is pretty good. They will reproduce the bug if they can.

 

[dsmagghe]

Which is the latest downloadable firmware that does not break sip messages?

 

[robmurphy]

I'm on holiday at the moment. I do not think the firmware I use is available for download. I'll be testing a new firmware with a "fix" over the next few weeks. I'm not overly confident in the fix as the people I have been dealing with thought they could not re-create the problem. It was only when they sent me a trace I was able to tell them they had re-created it.

The SMB range of products do not use the TAC team for problems.

If I was buying this type of router again I would look at the Draytek ones first.

Cisco have shot themselves in the foot with the lack of support for the RV0XX range of routers. The support for the switches is good and professional, the IP phones (SPA5xx) are great, but the router support sucks big time.

For SMB routers look at Draytek products.

Rob

 

[robmurphy]

I see Cisco has release a new firmware for these routers. The new firmware is version 4.2.1.02. This still has the problem with SIP messages. Check the release note.

Cisco claim they have fixed this, but they emailed me about it while I was on holiday, so was not able to dowload the beta firmware.

If the send me the link again I will try it, but apparently they have decided to implement a SIP ALG as well. To be honest the people I have been dealing with so far struggle to understand basic IP, let alone NAT, UDP, TCP.

Support for the SMB switches is streets ahead.

Rob

 

[RadiclDreamer]

Cisco tac is pretty good. They will reproduce the bug if they can.

I wonder what TAC you are getting, but I typically get someone that speaks english as a 5th language and can't understand the problems im trying to convey. I think TAC is the weakest link in Cisco unless you luck out and get the aussies or US.

 

[robmurphy]

The support for these routers is not TAC. The support is provided by another company, i.e. not Cisco.

I'm not joking when I say I have emailed Cisco saying that they should get rid of the company providing the support if they value the reputation of their SMB products.

To be honest I'm very close to replacing the Cisco SMB routers we have in the field with Draytek. Draytek make the Cisco SMB routers look like a very poor relation to an exceedingly cheap unknown brand router.

If HP could come up with good SIP phones, and a range of switches as good as the SF/SG300 range at a similar price I would drop Cisco completely after my experience of the so called support for the SMB routers.

I honestly think Cisco have lost the plot on this.

Rob.

 

[swappedsr]

Rob,

Did you ever find a solution, I am looking into purchasing one of these for two remote users that will have two cisco ip phones and a few computers. Not being able to turn of SIP ALG on the RV series worries me, because most people say that needs to be turned off and there isn't an option to do so it looks like. I am looking at the RV series because they are the very few that have more than 4 switch ports. If you could let me know as soon as possible you would be helping me out greatly as I have to get something ordered soon here.

 

[syco]

Cisco just release a new firmware today. V4.2.2.08 that is supposed to have a SIP fix for NAT. Here are the notes on it.

Fixed an issue where when multiple phones on the LAN used the same SIP port, the router changed the SIP ports on every registration and did not maintain existing NATing, which resulted in the foreign end bye getting dropped. (CSCty22521)

 

[swappedsr]

Hmm...been on the latest firmware, seem to work good for about a month and now calls are being dropped while on a call. Two users on this router with two ip phones. Strange how it worked for so long and now they are getting a bunch of drops where audio just goes out on their conference call, which is basically an all day call.

 

[kilthas]

My apologies for bumping an old thread, but in addition to the SIP fix mentioned in the notes from syco, the newest firmware does covertly expose SIP ALG option in the GUI. It's now listed with the hidden settings for the firewall general page (f_general_hidden.htm) along with the TCP and UDP timeout options. We have not yet tested this option, so ymmv.

 

[swappedsr]

Thanks Kilthas, this might help. We are still having issues of dropped calls for two of our remote workers using this router. Yesterday, they had about 5 or 6 dropped calls, once both phones dropped at the same time. Today, they had someone call and that caller said they went directly to voicemail. Not sure where to even look at this point, but I called my VOIP provider to see if they could help. Not sure that they will, because these are remote users and they are not on our VOIP provider's network. The strangest thing about this though is that VOIP always seems to work for about a month on this router and then it starts dropping calls. We received a replacement and it worked for a month, moved offices, and it worked for a month. Back to square one. Argh!!