[7.002] Got someone VoIP Security working?

Please describe your configuration in the VOIP Security.
What packet filters you have active.
Your NAT rules.
The definitions you are using.


Ian M

Okay, here is the configuration of ASG:
VOIP Security-> SIP Protocol Support:
SIP server networks: Any (and i tried also only my SIP Provider server)
SIP client networks: my VOIP-telephone IP.

VoIP Telephone configuration:
Everything is filled in correctly. All information is directing to my SIP Provider. Further IP/subnetmask is in the range of the LAN and gateway is directed to my ASG-box. The only important information is that:
Proxy server port: 5060
Registrar server port: 5060
Listen ports  
SIP port: 5060
RTP port: 5004

Used codecs: G711 a law & G729
STUN server and NAT is disabled.

I got a Siemens C450 IP VoIP-telephone. When VoIP security is disabled I can make calls and I hear the other party and the other party hears me. When VOIP Security is enabled can make a phone call, the other phone(s) are ringing but when it's picked up both party's don't hear anything!!!
In the Packet Filter Live Log the following is showed:
ulogd[2541]: id="2016" severity="info" sys="SecureNet" sub="packetfilter" name="SIP call RTP" action="SIP call RTP" fwrule="60018" initf="eth0" outitf="eth1" dstmac="xx:xx:xx:xx:xx:xx" srcmac="xx:xx:xx:xx:xx:xx" srcip="voip-phone ip" dstip="sip-provider ip" proto="17" length="200" tos="0x00" prec="0xc0" ttl="127" srcport="5004" dstport="36594" 
ulogd[2541]: id="2016" severity="info" sys="SecureNet" sub="packetfilter" name="SIP call RTP" action="SIP call RTP" fwrule="60018" initf="eth0" outitf="eth1" dstmac="xx:xx:xx:xx:xx:xx" srcmac="xx:xx:xx:xx:xx:xx" srcip="voip-phone ip" dstip="sip-provider ip" proto="17" length="200" tos="0x00" prec="0xc0" ttl="127" srcport="5004" dstport="36594"

And it fills so FAST that the live log must stop the script-window! I also tried to set the service SIP to UDP and not TCP but that doesn't help.Also I tried to set the RTP port to 20000 (for example) that doesn't do the trick. hopefully you have enough information otherwise please let me know.

Sorry I typed it wrong. I made a PF-rule but it still won't work.

fobe,
I will start a fresh testing sequence tomorrow night, now things have settled down a bit in my new job.

Ian M

Okay thanx a lot for your help. And I'll here from you soon.

fobe,
my setup which works
phone->pap2 -> asg->www

definition "RTP UDP" source 16384:16482 dest 1030:65535
definition "SIP UDP" source 5060 dest 5060
PF rule "voip phone" -> "RTP UDP" "voip phone provider" allow
PF rule "voip phone" -> "SIP UDP" "voip pnone provider" allow

Worked one way
SIP security enabled
PF "voip phone" -> "RTP UDP" "voip phone provider" allow
I had to add the ASG as a voip proxy in the PAP2 configuration otherwise lots of red messages. Now the ASG isn't a SIP proxy, so I am not sure where that leaves me.

the packet filter log shows lots of gray "SIP or H323" "SIP UDP" packets.
I could hear ring tone, but could only speak one way.


If I reversed the RTP definition nothing worked and the PF log filled with lots of red reject messages.

Conclusion - VOiP Security doesn't work. There is a distinct possibility that I needed to add something else to the PAP2 configuration when using ASG VOiP security, but I don't know what.

Obviously more experimentation is needed on my behalf.

Ian M

I know that VOiP Security isn't working! When i disable this feature my voip-phone works perfectly.

I am haven't given up yet, still playing. I  found you need the packet filter rule for the RTP around the wrong way to get traffic through.

It must work otherwise there would be more screams???[:S][:S][:S]

Ian M

I give up. I cannot make a 2 way call with voip security enabled.


Works fine otherwise.

I think there are more addresses in this argument than show up in the PF log because I get a couple of rejected packets at the start of the call.


Ian M

The bug is in the "the known issues list"

Ian M

As far as I can see, the issue has not been resolved in V7.003

Problem.
no outgoing voice.

Incoming voice works fine, including ringtone.

Setup
Voip provider has two SIP proxies with the same IP address and another box that responds that has a different IP address.

ASG 
SIP Helper - myvoip phone -> sip -> myvoip provider (has both voip provider addresses in it)
Packet filter - myvoip phone -> RTP (16348:16486) -> allow -> my voip provider

The packet filter log shows red packets dropped by default from the voip provider return address when they hit the ASG external address. Greyed packets outgoing from myvoip phone to the voip provider sip proxy address.

When I replace the SIP Helper with a packet filter rule that allows myvoip phone -> UDP (1030:65535) -> voip provider network (both addresses)-> (5060) that works without any dropped packets.

Ian M

Hi there all,

as there has many requests regarding the SIP proxy/helper not working as expected in V7, we investigated it.

First of all, the SIP proxy has been replaced by the SIP helper, as the proxy could only handle outbound SIP connects, the helper can handle inbound and outbound SIP connects. Means if you host your own SIP PBX, like many of our customers do, you need the helper.

We are aware that there still has been issues with the SIP helper under certain conditions.
I think we found the issue and have a solution:

In case you connect to bigger SIP-Provider, than they tend to process the RTP-Streams on a different host than the SIP data in order to do load balancing/sharing.

Our current SIP connection tracking helper assumes that the endpoint he talks to with SIP is also the endpoint he must sent the RTP-Streams to.

In a case, as we saw in packet dumps, the addresses were different.
the SIP connection used 217.10.79.9
the RTP connection used 217.10.68.67
(you can see this also in the attached screenshot sip_analyze.png)

this lead to the issue that the kernel expected the RTP connection to come from 217.10.79.9 but it actually came from 217.10.68.67, what you can also see from the packetfilter.log, as than this packet got dropped.

This should only happen if you use SNAT/Masquerading on the external interface towards the SIP provider.

For the smaller setups the sip-helper included in 7.003 should work as expected, but connection to bigger sip provider will fail.

We have a fix for that issue which will be released in one of the next up2dates.

You can check if you are affected by reading the packetfilter logfile, if the dropped RTP packet comes from a different IP address as where your SIP connection goes to, than you are affected by this issue.

i hope this clear's things up.

best regards
Gert

Hi there all,

as there has many requests regarding the SIP proxy/helper not working as expected in V7, we investigated it.

First of all, the SIP proxy has been replaced by the SIP helper, as the proxy could only handle outbound SIP connects, the helper can handle inbound and outbound SIP connects. Means if you host your own SIP PBX, like many of our customers do, you need the helper.

We are aware that there still has been issues with the SIP helper under certain conditions.
I think we found the issue and have a solution:

In case you connect to bigger SIP-Provider, than they tend to process the RTP-Streams on a different host than the SIP data in order to do load balancing/sharing.

Our current SIP connection tracking helper assumes that the endpoint he talks to with SIP is also the endpoint he must sent the RTP-Streams to.

In a case, as we saw in packet dumps, the addresses were different.
the SIP connection used 217.10.79.9
the RTP connection used 217.10.68.67
(you can see this also in the attached screenshot sip_analyze.png)

this lead to the issue that the kernel expected the RTP connection to come from 217.10.79.9 but it actually came from 217.10.68.67, what you can also see from the packetfilter.log, as than this packet got dropped.

This should only happen if you use SNAT/Masquerading on the external interface towards the SIP provider.

For the smaller setups the sip-helper included in 7.003 should work as expected, but connection to bigger sip provider will fail.

We have a fix for that issue which will be released in one of the next up2dates.

You can check if you are affected by reading the packetfilter logfile, if the dropped RTP packet comes from a different IP address as where your SIP connection goes to, than you are affected by this issue.

i hope this clear's things up.

best regards
Gert