[Serusers] rtpproxy + nathelper problem
Matt Schulte
mschulte at netlogic.net
Fri Dec 17 14:52:20 CET 2004
Remember to have NAT mapping enabled on the Sipura (Admin > Advanced > Line1), what kind of firewall/router are you using? It must be symmetric, meaning not only does the port 58698 have to remain open but SER must be able to communicate with your device on that same port. This is of course a common problem with NAT's.
I've had problems with linux firewalls running iptables, it would work fine until the UA would reboot, then it would register on another port and for some reason it just wouldn't traverse anymore. Small routers such as linksys, 3com, netgear work just peachy.
-----Original Message-----
From: support [mailto:support at cybertel.biz]
Sent: Wednesday, December 15, 2004 10:09 PM
To: Ricardo Martinez
Cc: serusers at lists.iptel.org
Subject: RE: [Serusers] rtpproxy + nathelper problem
Hi,
I use the ser.cfg below. I have rtpproxy running. Sipura 2000 can register now without STUN server. However, the registration port is 58698 not 5060.
Here is the SIP address after registration: sip:811 at 218.xxx.xxx.xxx:58698
Thomas
# ----------- global configuration parameters ------------------------
debug=3 # debug level (cmd line: -dddddddddd)
fork=yes
log_stderror=no # (cmd line: -E)
/* Uncomment these lines to enter debugging mode
fork=no
log_stderror=yes
*/
check_via=no # (cmd. line: -v)
dns=no # (cmd. line: -r)
rev_dns=no # (cmd. line: -R)
port=5060
children=4
fifo="/tmp/ser_fifo"
# ------------------ module loading ----------------------------------
# Uncomment this if you want to use SQL database
#loadmodule "/usr/local/lib/ser/modules/mysql.so"
loadmodule "/usr/local/lib/ser/modules/sl.so"
loadmodule "/usr/local/lib/ser/modules/tm.so"
loadmodule "/usr/local/lib/ser/modules/rr.so"
loadmodule "/usr/local/lib/ser/modules/maxfwd.so"
loadmodule "/usr/local/lib/ser/modules/usrloc.so"
loadmodule "/usr/local/lib/ser/modules/registrar.so"
loadmodule "/usr/local/lib/ser/modules/textops.so"
# Uncomment this if you want digest authentication
# mysql.so must be loaded !
#loadmodule "/usr/local/lib/ser/modules/auth.so"
#loadmodule "/usr/local/lib/ser/modules/auth_db.so"
# !! Nathelper
loadmodule "/usr/local/lib/ser/modules/nathelper.so"
# ----------------- setting module-specific parameters ---------------
# -- usrloc params --
modparam("usrloc", "db_mode", 0)
# Uncomment this if you want to use SQL database
# for persistent storage and comment the previous line #modparam("usrloc", "db_mode", 2)
# -- auth params --
# Uncomment if you are using auth module
#
#modparam("auth_db", "calculate_ha1", yes)
#
# If you set "calculate_ha1" parameter to yes (which true in this config),
# uncomment also the following parameter)
#
#modparam("auth_db", "password_column", "password")
# -- rr params --
# add value to ;lr param to make some broken UAs happy modparam("rr", "enable_full_lr", 1)
# !! Nathelper
modparam("registrar", "nat_flag", 6)
modparam("nathelper", "natping_interval", 30) # Ping interval 30 s
modparam("nathelper", "ping_nated_only", 1) # Ping only clients behind NAT
# ------------------------- request routing logic -------------------
# main routing logic
route{
# initial sanity checks -- messages with
# max_forwards==0, or excessively long requests
if (!mf_process_maxfwd_header("10")) {
sl_send_reply("483","Too Many Hops");
break;
};
if (msg:len >= max_len ) {
sl_send_reply("513", "Message too big");
break;
};
# !! Nathelper
# Special handling for NATed clients; first, NAT test is
# executed: it looks for via!=received and RFC1918 addresses
# in Contact (may fail if line-folding is used); also,
# the received test should, if completed, should check all
# vias for rpesence of received
if (nat_uac_test("3")) {
# Allow RR-ed requests, as these may indicate that
# a NAT-enabled proxy takes care of it; unless it is
# a REGISTER
if (method == "REGISTER" || ! search("^Record-Route:")) {
log("LOG: Someone trying to register from private IP, rewriting\n");
# This will work only for user agents that support symmetric
# communication. We tested quite many of them and majority is
# smart enough to be symmetric. In some phones it takes a configuration
# option. With Cisco 7960, it is called NAT_Enable=Yes, with kphone it is
# called "symmetric media" and "symmetric signalling".
fix_nated_contact(); # Rewrite contact with source IP of signalling
if (method == "INVITE") {
fix_nated_sdp("1"); # Add direction=active to SDP
};
force_rport(); # Add rport parameter to topmost Via
setflag(6); # Mark as NATed
};
};
# we record-route all messages -- to make sure that
# subsequent messages will go through our proxy; that's
# particularly good if upstream and downstream entities
# use different transport protocol
if (!method=="REGISTER") record_route();
# subsequent messages withing a dialog should take the
# path determined by record-routing
if (loose_route()) {
# mark routing logic in request
append_hf("P-hint: rr-enforced\r\n");
route(1);
break;
};
if (!uri==myself) {
# mark routing logic in request
append_hf("P-hint: outbound\r\n");
route(1);
break;
};
# if the request is for other domain use UsrLoc
# (in case, it does not work, use the following command
# with proper names and addresses in it)
if (uri==myself) {
if (method=="REGISTER") {
# Uncomment this if you want to use digest authentication
# if (!www_authorize("iptel.org", "subscriber")) {
# www_challenge("iptel.org", "0");
# break;
# };
save("location");
break;
};
lookup("aliases");
if (!uri==myself) {
append_hf("P-hint: outbound alias\r\n");
route(1);
break;
};
# native SIP destinations are handled using our USRLOC DB
if (!lookup("location")) {
sl_send_reply("404", "Not Found");
break;
};
};
append_hf("P-hint: usrloc applied\r\n");
route(1);
}
route[1]
{
# !! Nathelper
if (uri=~"[@:](192\.168\.|10\.|172\.(1[6-9]|2[0-9]|3[0-1])\.)" && !search("^Route:")){
sl_send_reply("479", "We don't forward to private IP addresses");
break;
};
# if client or server know to be behind a NAT, enable relay
if (isflagset(6)) {
force_rtp_proxy();
};
# NAT processing of replies; apply to all transactions (for example,
# re-INVITEs from public to private UA are hard to identify as
# NATed at the moment of request processing); look at replies
t_on_reply("1");
# send it out now; use stateful forwarding as it works reliably
# even for UDP2TCP
if (!t_relay()) {
sl_reply_error();
};
}
# !! Nathelper
onreply_route[1] {
# NATed transaction ?
if (isflagset(6) && status =~ "(183)|2[0-9][0-9]") {
fix_nated_contact();
force_rtp_proxy();
# otherwise, is it a transaction behind a NAT and we did not
# know at time of request processing ? (RFC1918 contacts)
} else if (nat_uac_test("1")) {
fix_nated_contact();
};
}
#-- end of config --
On Wed, 2004-12-15 at 21:39, Ricardo Martinez wrote:
> Hello Thomas.
> I think you're missing a few important things. First i don't see any
> checks for NAT'd endpoints, you need to do something like this:
>
> if (nat_uac_test(1))
> setflag(1);
> force_rport();
> fix_nated_contact();
>
> then in the INVITE:
>
> if (method=="INVITE") {
> record_route();
> if (isflagset(1))
> fix_nated_sdp("3");
> };
> /* set up reply processing */
> t_on_reply("1");
> };
>
> I'm using mediaproxy, so i am not sure about this, maybe somone that's
> using the nathelper module can help you better... you can check the
> example configuration file in the /modules/nathelper directory, that
> could give you some clues.
> +
> Cheers.
>
> Ricardo
>
> -----Mensaje original-----
> De: support [mailto:support at cybertel.biz]
> Enviado el: Miércoles, 15 de Diciembre de 2004 4:38
> Para: serusers at lists.iptel.org
> Asunto: [Serusers] rtpproxy + nathelper problem
>
>
> Hi,
>
> I have installed the latest rtpproxy and run it with ser-0.8-14. I
> have also include nathelper modules. When I try to register a siprua
> gateway with SER, the IP is still 192.168.1.xx. It cannot be
> translated to NAT public IP.
>
> Why is that so?
>
> Thanks.
>
>
> Thomas
>
>
> Appendix: my ser.cfg
> --------------------------------------------------
> #
> # $Id: ser.cfg,v 1.21 2003/06/04 13:47:36 jiri Exp $
> #
> # simple quick-start config script
> #
>
> # ----------- global configuration parameters
> ------------------------
>
> debug=3 # debug level (cmd line: -dddddddddd)
> fork=yes
> log_stderror=no # (cmd line: -E)
>
> /* Uncomment these lines to enter debugging mode
> debug=7
> fork=no
> log_stderror=yes
> */
>
> check_via=no # (cmd. line: -v)
> dns=no # (cmd. line: -r)
> rev_dns=no # (cmd. line: -R)
> port=5060
> children=4
> fifo="/tmp/ser_fifo"
>
> alias=mydomain.dyndns.org
>
> # ------------------ module loading
> ----------------------------------
>
>
> loadmodule "/usr/local/lib/ser/modules/nathelper.so"
> loadmodule "/usr/local/lib/ser/modules/textops.so"
> loadmodule "/usr/local/lib/ser/modules/sl.so"
> loadmodule "/usr/local/lib/ser/modules/tm.so"
> loadmodule "/usr/local/lib/ser/modules/rr.so"
> loadmodule "/usr/local/lib/ser/modules/maxfwd.so"
> loadmodule "/usr/local/lib/ser/modules/usrloc.so"
> loadmodule "/usr/local/lib/ser/modules/registrar.so"
>
>
> # ----------------- setting module-specific parameters ---------------
> # -- usrloc params --
> modparam("usrloc", "db_mode", 0)
>
>
> # -- rr params --
> # add value to ;lr param to make some broken UAs happy
> modparam("rr", "enable_full_lr", 1)
>
> # ------------------------- request routing logic
> -------------------
>
> # main routing logic
>
> route{
>
> # initial sanity checks -- messages with
> # max_forwards==0, or excessively long requests
> if (!mf_process_maxfwd_header("10")) {
> sl_send_reply("483","Too Many Hops");
> break;
> };
> if (len_gt( max_len )) {
> sl_send_reply("513", "Message too big");
> break;
> };
>
> # we record-route all messages -- to make sure that
> # subsequent messages will go through our proxy; that's
> # particularly good if upstream and downstream entities
> # use different transport protocol
> record_route();
> # loose-route processing
> if (loose_route()) {
> t_relay();
> break;
> };
>
> # if the request is for other domain use UsrLoc
> # (in case, it does not work, use the following command
> # with proper names and addresses in it)
> if (uri==myself) {
>
> if (method=="REGISTER") {
> save("location");
> break;
> };
>
> # native SIP destinations are handled using our USRLOC DB
> if (!lookup("location")) {
> sl_send_reply("404", "Not Found");
> break;
> };
> };
>
> #inserted by klaus
> if (method=="INVITE") {
> record_route();
> force_rtp_proxy();
> /* set up reply processing */
> t_on_reply("1");
> };
>
>
> # forward to current uri now; use stateful forwarding; that
> # works reliably even if we forward from TCP to UDP
> if (!t_relay()) {
> sl_reply_error();
> };
>
> }
>
> #inserted by klaus
> # all incoming replies for t_onrepli-ed transactions enter here
> onreply_route[1] {
> if (status=~"[12][0-9][0-9]")
> force_rtp_proxy();
> }
>
> _______________________________________________
> Serusers mailing list
> serusers at lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
>
> _______________________________________________
> Serusers mailing list
> serusers at lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
--
Cybertel Works Ltd.
Unit 12, 6/F, Tower B, New Trade Plaza,
6 On Ping Street, Shatin, N.T., Hong Kong
Tel. : 852 - 2637 2221
Fax.: 852 - 2541 1535
Email : support at cybertel.biz
Website : www.cybertel.biz
_______________________________________________
Serusers mailing list
serusers at lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
More information about the sr-users
mailing list