Q on VoIPo SIP outbound vs. router

[stevech]

Trying this question here before I file a trouble ticket...
My router's event log (syslog stored internally), has several per minute notices. Each says the router blocked a SIP packet from the Grandstream ATA directed to server 72.51.46.124:5060. This is OUTBOUND.

My router has firewall settings for SIP/ALG and this is enabled. I assume this is for inbound SIP connections (receiving a call).

The firewall settings in the router do not have anything specific on blocking ports for OUTBOUND.

Port-forwarding for inbound seems N/A for this discussion, but it's enabled none the less, to forward to the ATA.

The exact router message is "SIP ALG rejected packet from 192.168.1.51:5079 to 72.51.46.124:5060" (where .51 is the Grandstream on the LAN) All log messages have the same destination SIP server IP.

which suggests that the ALG in the router decided the SIP packet is invalid and should not be forwarded to the Internet?

I also tried putting the ATA in the router's DMZ. No help.

All this does is quickly fill up my router's log. It may also be a problem when the ATA tries to contact a designated SIP server for registration, but I have no loss of service problems for registration.

[holmes4]

Can you turn ALG off? This is often recommended.

[stevech]

Can you turn ALG off? This is often recommended.
Yes, I can turn ALG/SIP off, and a list of others such as MMS, IPsec, PPTP, and RTSP. The latter is used by VoIP for the bearer traffic, right?

Is the purpose of router-based ALG to avoid the need to do explicit port-forwarding or "triggered" forwarding, etc? I don't know.

[voipinit]

VOIPo is sending keep alive packets to keep customers routers ports from closing. Your router settings are set not to reply (permit an outbound packet) to an inbound packet request that is only a single packet reply to a solicitation (similar to blocking WAN ping requests). If you are not having registration issues or call quality issues, I wouldn't worry about it and keep your current configuration.

[stevech]

Your router settings are set not to reply (permit an outbound packet) to an inbound packet request that is only a single packet reply to a solicitation (similar to blocking WAN ping requests). What setting would prohibit a reply initiated by the ATA?

[voipinit]

I'll tell you what I know:

To answer your question it is most likely SIP ALG but I don't know your other options either configurable or not configurable (if any) regarding the routers firewall.

SIP ALG is supposed to do 3 things (few commercial routers do this well - most don't):

Open the appropriate ports for VOIP traffic.
Check VOIP packets to ensure it complies with SIP protocols.
Allow auditing by producing log messages.

My guess:
It appears your router SIP ALG is accepting the incoming keep alive from VOIPo like it should since it is valid VOIP traffic, but is not accepting your ATA's reply (and thus generates a log message). This could be from SIP ALG not recognizing the ATA's reply as VOIP traffic or it not complying with the routers SIP ALG algorithm violating the SIP protocol (either correctly or incorrectly).

[stevech]

I'll tell you what I know:

To answer your question it is most likely SIP ALG but I don't know your other options either configurable or not configurable (if any) regarding the routers firewall.

SIP ALG is supposed to do 3 things (few commercial routers do this well - most don't):

Open the appropriate ports for VOIP traffic.
Check VOIP packets to ensure it complies with SIP protocols.
Allow auditing by producing log messages.

My guess:
It appears your router SIP ALG is accepting the incoming keep alive from VOIPo like it should since it is valid VOIP traffic, but is not accepting your ATA's reply (and thus generates a log message). This could be from SIP ALG not recognizing the ATA's reply as VOIP traffic or it not complying with the routers SIP ALG algorithm violating the SIP protocol (either correctly or incorrectly).
re your last paragraph: I suspect that too- that the Grandstream is generating a packet that the router's ALG outgoing cannot validate. It sees that it's SIP, but something else is invalid.
I don't think this is related to the incoming from the various VoIOo partner servers - the router is normally set to drop these and not forward, since they serve no purpose in my router. And when I did put the ATA in the DMZ where the incoming are accepted, it made no difference- the outgoing packets from the Grandstream are rejected by the ALG none the less.

I will check again with VoIPo tech support. I believe that the Grandstream's attempts at outgoing SIP may be registration or keep-alive notices. Last ticket I filed was due to loss of service. VoIPo noted that my ATA wasn't being provisioned. They didn't say why but did the usual hail-mary fix: Upgrade the ATA's firmware version and hope.

[voipinit]

What may be happening is the keep alive packet has your local LAN IP as the return IP . Local LAN IP's are not routable, so your router correctly rejects it. This process appears to be working as designed.

[caseydoug]

I get a lot of blocked outbound ICMP (Type 3) packets from my ATA, and I have SIP ALG turned off. I was told by support that this is normal.

[sr98user]

There are 3 things in play here..

SIP ALG - which rewrites SIP header with public IP and public port.
If this is on and it works correctly then you probably don't need a
STUN server.
Firewall - which inspects UDP/TCP sessions and open/closes port ASAP.
Probably does other things too. Like DOS attack etc.
NAT - which maps and internal IP/port to external IP/port. There are different
types of NAT. But its mostly about directing/blocking traffic from WAN.
My guess is probably the Firewall (maybe NAT is involved) that is blocking your outgoing traffic. In your original post you mentioned that it tries to block traffic to 72.51.46.124. That is sip-west.voipwelcome.com. Is that where you are connected to? I thought that server was not up and running.

[stevech]

Yes, I'm served by the west SIP server.

I would like to stop all the outbound rejections because it fills up my router's SYSLOG. And the barrage (3 per minute) of incoming "pings" from SIP servers is bad too.

I didn't have all this with my prior VoIP provider. But that provider did not have a reliable server feature set, nor humane customer support.

[sr98user]

If you are getting 3 per minute, its probably the keep alive packets from the ATA to the SIP server to keep the UDP NAT entries alive. I am not sure why your router is blocking that traffic. Does it give any reason at all? What router do you have?

Depending on the NAT entry timeout for the UDP packets, you could increase the keep alive interval. To do that, you would need to the timeout or should be able to configure it.

[stevech]

If you are getting 3 per minute, its probably the keep alive packets from the ATA to the SIP server to keep the UDP NAT entries alive. I am not sure why your router is blocking that traffic. Does it give any reason at all? What router do you have?

Depending on the NAT entry timeout for the UDP packets, you could increase the keep alive interval. To do that, you would need to the timeout or should be able to configure it.
I am seeing my router's log (Cradlepoint MBR900) filled with rejected incoming packets from VoIPo's SIP servers. Also, my ATA's ALG function is trying to send SIP packets out but the router log says it did not forward, apparently because the Grandstream's SIP packet is not formatted properly according to the Cradlepoint.

[voipinit]

... Also, my ATA's ALG function is trying to send SIP packets out but the router log says it did not forward, apparently because the Grandstream's SIP packet is not formatted properly according to the Cradlepoint.

Keep alive packets from your ATA are sent to keep your router ports open, not VOIPo's. The ATA is sending a local request to your router, a local request (local IP, private IP, any IP starting with 192.168) cannot be forwarded, if local IP's forwarded to the internet you would be colliding with millions of routers worldwide. Your registration requests are getting forwarded because the ATA sends it thru your WAN IP address. As long as your ATA is keeping your routers ports open (or your router has built in VOIP logic), you are right, VOIPo's attempt to keep yours alive is unnecessary. But, they have more than just you to think about, thousands of VOIPo customers are benefiting from keep alive requests sent by VOIPo and it is not detrimental to routers that don't need the reminder. Albeit maybe a little unnerving seeing your logs fill up.

[stevech]

Keep alive packets from your ATA are sent to keep your router ports open, not VOIPo's. The ATA is sending a local request to your router, a local request (local IP, private IP, any IP starting with 192.168) cannot be forwarded, if local IP's forwarded to the internet you would be colliding with millions of routers worldwide. Your registration requests are getting forwarded because the ATA sends it thru your WAN IP address. As long as your ATA is keeping your routers ports open (or your router has built in VOIP logic), you are right, VOIPo's attempt to keep yours alive is unnecessary. But, they have more than just you to think about, thousands of VOIPo customers are benefiting from keep alive requests sent by VOIPo and it is not detrimental to routers that don't need the reminder. Albeit maybe a little unnerving seeing your logs fill up. Geeze, I know the difference between a non-routable/private IP and a public IP address. The problem is why does my router's ALG reject the SIP packets form the Grandstream. If not rejected, they get NATed to my public address and on to VoIPo's designated SIP server. I will try to get from Cradlepoint what criteria they use to reject a SIP packet in their ALG.

[voipinit]

I wonder if SIP ALG is re-writing the packet to use your public IP as opposed to using NAT and discarding the original. Does your traffic decrease with SIP ALG disabled?

[stevech]

I wonder if SIP ALG is re-writing the packet to use your public IP as opposed to using NAT and discarding the original. Does your traffic decrease with SIP ALG disabled?
While I await a response from Cradlepoint tech support, all I can say is what the log says

"SIP ALG rejected packet from 192.168.1.51:5079 to 72.51.46.124:5060"

where the source is the VoIP device and the destination is the SIP server I am assigned. One must assume that the packet would get NATed to my public IP address had ALG not rejected it as formatted by the Grandstream.

EDIT: I did find this statement from a lay-person:
"As most modern sip clients are NAT aware, there really isn't a need for the sip alg."
But I wonder if this applies to the NAT traversal techniques in the Grandstream client?


To be clear: The VoIPo service works OK, this is an admin issue.

[sr98user]

NAT Keep alive packets probably don't have any SIP header.. That maybe the reason it is rejecting the packets.

Since you are working fine with the packets being rejected, I assume you don't need any keep alive packets. You could probably ask VOIPo to turn off Keep Alive packets. Since your router is SIP aware, it is getting the registration interval from the SIP packets and keeping the NAT entry alive for the duration.

I am not sure if STUN setting is turned on for your ATA. If not, your router's SIP ALG is working fine. If the SIP ALG is turned off in your router, you will need NAT Traversal and STUN server on your ATA.

On my ATA, NAT Traversal, STUN and Keep alive packets are turned off.

[voipinit]

NAT Keep alive packets probably don't have any SIP header.. That maybe the reason it is rejecting the packets.

Sounds correct, if keep alive packets had a valid SIP header, it would be passed just like registration requests are.



On my ATA, NAT Traversal, STUN and Keep alive packets are turned off.

On my ATA, NAT traversal (STUN) and keep alive are on (keep alive sent every 20 seconds but really is just bouncing back and forth between the router and ATA).

[stevech]

Do I have this correct:
The Grandstream ATA is sending "keep alive" packets to the SIP server, on the SIP port, but these are not SIP-formatted (standards-compliant). Therefore, the ALG in my router rejects them. So they should not be sent on the SIP port. Yes?

VoIPo told me they moved my ATA to non-standard SIP ports to better hide from bad guys trying to steal service. Not sure this is relevant.

The keep-alive packets, if this is what they are, seemingly should be sent via some port number that is not reserved by agreement for a given service like SIP.
Yes?

It would be noise on the LAN but my router's log fills quickly with these junk messages, and those of rejected incoming messages from VoIPo's SIP servers doing some sort of NAT trigger keep-alive. I'd really like my router's log to be useful for what it is intended for: logging anomalies.

[sr98user]

Do I have this correct:
The Grandstream ATA is sending "keep alive" packets to the SIP server, on the SIP port, but these are not SIP-formatted (standards-compliant). Therefore, the ALG in my router rejects them. So they should not be sent on the SIP port. Yes?

Your router log says that SIP ALG functionality rejected it. But I am not sure if the packet is still sent out without being rewritten by SIP ALG. Cradlepoint can confirm that for you.



VoIPo told me they moved my ATA to non-standard SIP ports to better hide from bad guys trying to steal service. Not sure this is relevant.

The keep-alive packets, if this is what they are, seemingly should be sent via some port number that is not reserved by agreement for a given service like SIP. Yes?


VOIPo could have just changed the port on your side to avoid the "bad guys stealing service" problem. I am not sure if they changed both the local port and the destination port. Given that SIP ALG is kicking in on your router, I would guess that VOIPo changed only the local port.

I know that you can access VOIPo service at ports other than 5060. Like 5061, 5062, 5078 etc..



It would be noise on the LAN but my router's log fills quickly with these junk messages, and those of rejected incoming messages from VoIPo's SIP servers doing some sort of NAT trigger keep-alive. I'd really like my router's log to be useful for what it is intended for: logging anomalies.

Is your router rejecting incoming packets from multiple SIP servers or just one? I know your service works fine, but rejecting incoming packets from SIP servers it not the ideal setup.

[stevech]

The log entries are an about equal mix of outgoing packets from the grandstream that are blocked as apparently invalid SIP packets, by the ALG in the router. Others here said it's probably keep-alive packets sent on the SIP port but without a SIP header; and incoming packets from VoIPo's SIP servers, apparently in an attempt to cope with some consumer routers that won't work correctly for NAT without this barrage of ping-like packets.