OpenWrt Forum Archive

Topic: SIP connection tracking

The content of this topic has been archived on 16 Mar 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Hello All!

I`m trying to run my Asterisk server behind NAT. I couldn't figure out why and when the NAT helper modules went missing from OpenWRT.
They are rather crucial if you are trying to have SIP devices/servers behind NAT without STUN. 
I now, they have been there in the package "kmod-ipt-nathelper-extra".  The both modules are called: ip_conntrack_sip and ip_nat_sip.
They are part of any decent distro nowadays, but they just vanished from Kamikaze.
Could you please provide some info on this problem, I can't believe, I'm the only one with this trouble.

Thank you in advance!

Exnor

Which version of kamikaze?

(I had been thinking of moving my asterisk off my OpenWrt box at some stage, so it is good for me to know what problems there are)

Hi!

Thank you for the answer!
The NAT helper modules for specific protocols seem to be in :
http://downloads.openwrt.org/kamikaze/8 … mipsel.ipk
Too bad the modules for SIP are not included:

./
./lib/
./lib/modules/
./lib/modules/2.4.35.4/
./lib/modules/2.4.35.4/ip_conntrack_amanda.o
./lib/modules/2.4.35.4/ip_conntrack_proto_gre.o
./lib/modules/2.4.35.4/ip_nat_proto_gre.o
./lib/modules/2.4.35.4/ip_conntrack_h323.o
./lib/modules/2.4.35.4/ip_nat_h323.o
./lib/modules/2.4.35.4/ip_conntrack_mms.o
./lib/modules/2.4.35.4/ip_nat_mms.o
./lib/modules/2.4.35.4/ip_conntrack_pptp.o
./lib/modules/2.4.35.4/ip_nat_pptp.o
./lib/modules/2.4.35.4/ip_conntrack_rtsp.o
./lib/modules/2.4.35.4/ip_nat_rtsp.o
./lib/modules/2.4.35.4/ip_nat_snmp_basic.o
./etc/
./etc/modules.d/
./etc/modules.d/45-ipt-nathelper-extra

Exnor

Hi All!

No luck yet, so I will need to have siproxd runnig on OpenWRT as a frontend for my Asterisk.
Still, please let me know if someone has some Information on the fate of the SIP helper modules! They could be important to anyone running SIP behind a low cost router.   

Yours !

Exnor

Ps. is there a painless way to compile a kernel by myself? Some good howtos maybe?
(I have done it several times for my PC, but a cross compile for that small box is quite a big obstacle for me, as an ordinary user.)

exnor wrote:

No luck yet, so I will need to have siproxd runnig on OpenWRT as a frontend for my Asterisk.

Siproxd is pretty cool anyway and probably a more elegant solution, use ifconfig to ID interfaces, on my WRT54GL I set up /etc/siproxd.conf with
if_inbound  = br-lan
if_outbound = eth0.1
and also
registration_file = /tmp/siproxd_registrations
pid_file = /tmp/run/siproxd/siproxd.pid
the at the bottom of /etc/firewall.user
# transparently redirect SIP traffic to siproxd
iptables -t nat -A prerouting_rule -p udp -i br-lan --dport 5060 -j REDIRECT

# allow incoming SIP and RTP traffic
iptables -A input_wan -p udp --dport 5060      -j ACCEPT
iptables -A input_wan -p udp --dport 7070:7089 -j ACCEPT

One issue is that versions of siproxd prior to 0.6.0 don't proxy RTCP with the result was that data streams that utilise RTCP (usually Video) look awful, Kamikaze 7.09 uses siproxd 0.5.13-1 while 8.09 RC1 currently has 07.1-1 but I can't get 8.09 with qos stable so there's a problem somewhere.
http://forum.openwrt.org/viewtopic.php?id=15531

Good luck

(Last edited by stunted on 9 Jan 2009, 02:41)

Hi Stunted!

Thanks a lot, any info on this topic is very much appreciated. Your reply doesn't sound very promising, I'm wondering if I just should take something like a normal PC with a full blown distro as a router. Still I'll give it a try this weekend, and should I succeed I'll post my results here.

I would still like to hear something about those NAT helper modules, VoIP seems to be neglected a bit by the developers.
Anyway OpenWRT is a great thing, please keep up the great job, and thanks for the development, but please, please put those NAT helpers back into there! smile

Exnor

exnor wrote:

Hi Stunted!

Thanks a lot, any info on this topic is very much appreciated. Your reply doesn't sound very promising, I'm wondering if I just should take something like a normal PC with a full blown distro as a router. Still I'll give it a try this weekend, and should I succeed I'll post my results here

I don't mean to sound down, I'm just doing battle to get 8.09 with siproxd and qos running and stable on my WRT54GL, if you don't use video then 7.09 and siproxd 0.5 will work *very* nicely for you.

You run Asterisk in-side the network, I don't at the moment so I don't know if that means *all* the SIP traffic comes from / to the Asterisk box or if it just acts as a registrar and the actual traffic is still P2P, in the first case then just forwarding the relevant ports to the Asterisk box would probably work, in the later you still need some assistance with NAT traversal.

One alternative I've used is you run stable software (7.09 or in my previous case Debian etch) on the internet facing firewall without siproxd but with relevant ports forwarded to an internal box that runs more bleeding edge software (8.09 or in my previous case Debian Lenny) and a more up-to-date version of siproxd, that way video works as well and you don't have to run beta software on your firewall, the disadvantage is you loose the ability to make the proxy transparent and have to set all your SIP clients to use the internal box as their outbound proxy.

I can't wait for 8.09 and / or lenny to go stable as then these issues go away.

HI,

Based on the above post by Stunted, I am running 8.09.1 and I have to install  iptables-mod-nat-extra to get ipt_REDIRECT.ko installed so the "REDIRECT" will work. I don't have to creat /etc/siproxd.conf as existing siproxd.conf under /var/run..... seems working fine.

(https://dev.openwrt.org/browser/trunk/package/iptables/Makefile?rev=12649 (define Package/iptables-mod-nat-extra/description
173     iptables extensions for extra NAT targets.
174     Includes:
175     - REDIRECT)

for the firewall config,

***from /etc/firewall.user
# transparently redirect SIP traffic to siproxd
iptables -t nat -A prerouting_rule -p udp -i br-lan --dport 5060 -j REDIRECT

**from /etc/config/firewall
config rule                                                                     
        option src      wan                                                     
        option src_dport        5060                                           
        option target   ACCEPT                                                 
        option protocol udp                                                     
config rule                                                                     
        option src      wan                                                     
        option src_dport        7070-7089                                       
        option target   ACCEPT                                                 
        option protocol udp         

root@WRT_CAN:~# uname -a
Linux WRT_CAN 2.6.25.20 #4 Mon Jun 1 23:39:13 UTC 2009 mips unknown.

BTW,

I was trying to use new firewall configuration method to achieve "iptables -t nat -A prerouting_rule -p udp -i br-lan --dport 5060 -j REDIRECT" and not do this in /etc/firewall.user, but doesn't work.

config in /etc/config/firewall:
config redirect
      option src              lan
      option src_dport        5060
      option target           REDIRECT

Does anyone know whether this is confired wrong or it can't be accieved in /etc/config/firewall, but only achieved in /etc/firewall.user. ?

thanks




thanks
Peng

(Last edited by peng on 5 Sep 2009, 23:18)

Hi Guys,

Can some body give shed some light? What can I do to make this work? Is it a bug?

When my phone is registering to a proxy not using standard 5060 port,say 8060, siproxd sill modifies it to 5060 and send out registration ( i guess it's true for invite as well). It would be wrong for it does this and it should only modify source ip/port. I did changed listen port in the siproxd.

Here's a tcpdump.

5:38:15.142620 IP 221.209.xx.xx.8060 > xxxx.dsl.xxx.com.5060:

thanks in advance.
peng

(Last edited by peng on 4 Oct 2009, 10:54)

The discussion might have continued from here.