News: This forum is now permanently frozen.
linktree m0n0wall Forum  >  m0n0wall Support (English)  >  Bug Reports  >  Resolved
linktree Topic: Bug in VOIP handling/ipfilter inbound NAT RDR problem with SIP
Pages: [1]
Topic: Bug in VOIP handling/ipfilter inbound NAT RDR problem with SIP  (Read 8713 times)
« on: October 02, 2008, 20:25:21 »
hairguy *
Posts: 2
When I run a VOIP  test at http://www.aptela.com/voiptest/ with my Monowall, it fails parts on some of the VOIP signaling tests (SIP connection and SIP reply). 

However, I have several VOIP phones and they work fine behind the firewall.

Someone else appears to have identified the problem here, but I don't know if the bug has been reported to Monowall:
http://www.usenet-forums.com/ipfilter/396962-ipfilter-inbound-nat-rdr-problem-sip.html

==================================================================
This is a discussion on ipfilter inbound NAT RDR problem with SIP within the IPFilter forums, part of the System Security and Security Related category; Hi, m0n0wall firewalls since version 1.3b5 up to the latest 1.3b13, do fail for some users trying to ...


m0n0wall firewalls since version 1.3b5 up to the latest 1.3b13, do fail for
some users trying to register with some SIP providers.

They use inbound NAT redirects for UDP port 5060 (SIP) but fail to
receive INVITE's from the provider they're registered with.
It worked with m0n0wall version 1.3b4 and earlier.

I traced the problem down to a check for active redirects added with
ipfilter 1.4.16 and documented below the details as well as a fix that worked
for me.

System description:

m0n0wall 1.3b13 (first reported with 1.3.b5)
FreeBSD 6.3-RELEASE-p1 #0: Sun Jul 13 11:49:59 CEST 2008
root@mb63.neon1.net:/usr/src/sys/i386/compile/M0N0WALL_WRAPALIX
ipfilter 4.1.28

sis0: Inside NAT lan interface ip 192.168.2.1
sis1: Outside NAT wan interface ip x.237.224.134


What happens:

An active SIP registration between lan side SIP device and a public SIP
server creates an active NAT mapping entry like this one:
MAP 192.168.2.129 5060 <- -> x.237.224.134 33552 [193.16.148.244 5060]

When the SIP server sends the following SIP INVITE packet to the
outside interface:
IP 193.16.148.244.5060 > x.237.224.134.5060: SIP, length: 1118
it gets blocked by NAT and counted as 'bad nat'.

Resetting NAT to get rid of the active mapping allows the INVITE to go
thru and create an active redirect mapping like this one:
RDR 192.168.2.129 5060 <- -> x.237.224.134 5060 [193.16.148.244 5060]


my Analysis and fix so far:

ipfilter 4.1.13 worked for this specifc case but later version don't.
I traced it down to an additional check for active redirect mappings
in nat_newrdr():
/*
* Check to see if this redirect mapping already exists and if
* it does, return "failure" (allowing it to be created will just
* cause one or both of these "connections" to stop working.)
*/

inb.s_addr = htonl(in.s_addr);
sp = fin->fin_data[0];
dp = fin->fin_data[1];
fin->fin_data[1] = fin->fin_data[0];
fin->fin_data[0] = ntohs(nport);
natl = nat_outlookup(fin, flags & ~(SI_WILDP|NAT_SEARCH),
(u_int)fin->fin_p, inb, fin->fin_src);
fin->fin_data[0] = sp;
fin->fin_data[1] = dp;
if (natl != NULL)
return -1;

This got introduced with ipfilter 4.1.16:

http://ipfilter.cvs.sourceforge.net/...2.6&r2=1.2.2.7

When I disable this check for existing redirects, the INVITE's make it thru
and create an active redirect NAT entry:
DR 192.168.2.129 5060 <- -> 99.237.224.134 5060 [193.16.148.244 5060]

It seems, the introduced check for an existing redirect wrongly took an active
MAP mapping for an active redirect.

Could this check be modified so it only checks for active redirects?

Is this check still required at all?

Hope I documented all the information and my apology if not.

The details with reproducable results using single packet injection from
either side are below. I can make the packets in pcap form available on
request

Thanks!

Marcel



clean NAT status:
-------------------------------------------------------------------
$ ipnat -slv
mapped in 0 out 0
added 0 expired 0
no memory 0 bad nat 0
inuse 0
orphans 0
rules 9
wilds 0
hash efficiency 0.00%
bucket usage 0.00%
minimal length 0
maximal length 0
average length 0.000
table 0xbfbfeb7c list 0xc203e200
TCP Entries per state
0 1 2 3 4 5 6 7 8 9 10 11
0 0 0 0 0 0 0 0 0 0 0 0
List of active MAP/Redirect filters:
map sis1 192.168.2.0/24 -> 0.0.0.0/32 proxy port ftp ftp/tcp
map sis1 192.168.2.0/24 -> 0.0.0.0/32 portmap tcp/udp auto
map sis1 192.168.2.0/24 -> 0.0.0.0/32
map sis1 192.168.2.208/28 -> 0.0.0.0/32 proxy port ftp ftp/tcp
map sis1 192.168.2.208/28 -> 0.0.0.0/32 portmap tcp/udp auto
map sis1 192.168.2.208/28 -> 0.0.0.0/32
rdr sis1 0.0.0.0/0 port 4569 -> 192.168.2.129 port 4569 udp
rdr sis1 0.0.0.0/0 port 5060 -> 192.168.2.129 port 5060 udp
rdr sis1 0.0.0.0/0 port 20001-20100 -> 192.168.2.129 port 20001 udp

List of active sessions:

List of active host mappings:

-------------------------------------------------------------------
status after sending 1 UDP SIP option packet out:
IP 192.168.2.129.5060 > 193.16.148.244.5060: SIP, length: 497
-------------------------------------------------------------------
$ ipnat -slv
mapped in 0 out 1
added 1 expired 0
no memory 0 bad nat 0
inuse 1
orphans 0
rules 9
wilds 0
hash efficiency 100.00%
bucket usage 0.01%
minimal length 0
maximal length 1
average length 1.000
table 0xbfbfeb7c list 0xc203e200
TCP Entries per state
0 1 2 3 4 5 6 7 8 9 10 11
0 0 0 0 0 0 0 0 0 0 0 0
List of active MAP/Redirect filters:
map sis1 192.168.2.0/24 -> 0.0.0.0/32 proxy port ftp ftp/tcp
map sis1 192.168.2.0/24 -> 0.0.0.0/32 portmap tcp/udp auto
map sis1 192.168.2.0/24 -> 0.0.0.0/32
map sis1 192.168.2.208/28 -> 0.0.0.0/32 proxy port ftp ftp/tcp
map sis1 192.168.2.208/28 -> 0.0.0.0/32 portmap tcp/udp auto
map sis1 192.168.2.208/28 -> 0.0.0.0/32
rdr sis1 0.0.0.0/0 port 4569 -> 192.168.2.129 port 4569 udp
rdr sis1 0.0.0.0/0 port 5060 -> 192.168.2.129 port 5060 udp
rdr sis1 0.0.0.0/0 port 20001-20100 -> 192.168.2.129 port 20001 udp

List of active sessions:
MAP 192.168.2.129 5060 <- -> x.237.224.134 33552 [193.16.148.244 5060]
ttl 1049 use 0 sumd 0xf096/0xf096 pr 17 bkt 12759/14406 flags 2
ifp X,X bytes 0/525 pkts 0/1 ipsumd 814a

List of active host mappings:
192.168.2.129,193.16.148.244 -> 0.0.0.0 (use = 2 hv = 0)

-------------------------------------------------------------------
status after receiving unrelated UDP SIP INVITE from the outside:
IP 193.16.148.244.5060 > x.237.224.134.5060: SIP, length: 1118
-------------------------------------------------------------------
$ ipnat -slv
mapped in 0 out 1
added 1 expired 0
no memory 0 bad nat 1
inuse 1
orphans 0
rules 9
wilds 0
hash efficiency 100.00%
bucket usage 0.01%
minimal length 0
maximal length 1
average length 1.000
table 0xbfbfeb7c list 0xc203e200
TCP Entries per state
0 1 2 3 4 5 6 7 8 9 10 11
0 0 0 0 0 0 0 0 0 0 0 0
List of active MAP/Redirect filters:
map sis1 192.168.2.0/24 -> 0.0.0.0/32 proxy port ftp ftp/tcp
map sis1 192.168.2.0/24 -> 0.0.0.0/32 portmap tcp/udp auto
map sis1 192.168.2.0/24 -> 0.0.0.0/32
map sis1 192.168.2.208/28 -> 0.0.0.0/32 proxy port ftp ftp/tcp
map sis1 192.168.2.208/28 -> 0.0.0.0/32 portmap tcp/udp auto
map sis1 192.168.2.208/28 -> 0.0.0.0/32
rdr sis1 0.0.0.0/0 port 4569 -> 192.168.2.129 port 4569 udp
rdr sis1 0.0.0.0/0 port 5060 -> 192.168.2.129 port 5060 udp
rdr sis1 0.0.0.0/0 port 20001-20100 -> 192.168.2.129 port 20001 udp

List of active sessions:
MAP 192.168.2.129 5060 <- -> x.237.224.134 33552 [193.16.148.244 5060]
ttl 458 use 0 sumd 0xf096/0xf096 pr 17 bkt 12759/14406 flags 2
ifp X,X bytes 0/525 pkts 0/1 ipsumd 814a

List of active host mappings:
192.168.2.129,193.16.148.244 -> 0.0.0.0 (use = 2 hv = 0)

Reply With Quote
Marcel Wiget
Reply

Thread Tools
Show Printable Version Show Printable Version
Email this Page Email this Page
Display Modes
Linear Mode Linear Mode
Hybrid Mode Switch to Hybrid Mode
Threaded Mode Switch to Threaded Mode
Search this Thread

Advanced Search
Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
BB code is On
Smilies are Off
[IMG] code is Off
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On
   



All times are GMT +1. The time now is 07:13 PM.

   
Contact Us - Usenet Forums - Archive - Top
   

Powered by vBulletin® Version 3.7.3
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO 3.0.0
LinkBack
LinkBack URL LinkBack URL
About LinkBacks About LinkBacks
« Reply #1 on: October 02, 2008, 21:42:27 »
Manuel Kasper
Administrator 		*****
Posts: 364
Quote from: hairguy on October 02, 2008, 20:25:21
Someone else appears to have identified the problem here, but I don't know if the bug has been reported to Monowall:
http://www.usenet-forums.com/ipfilter/396962-ipfilter-inbound-nat-rdr-problem-sip.html

Marcel Wiget (a m0n0wall contributor) has identified this ipfilter bug and reported it on the ipfilter mailing list. Unfortunately, nobody seems to have cared about it, so we're not sure what to do. We've been contemplating to reverse the code changes that introduced the described problem in ipfilter 4.1.16, which would make this particular case of SIP/RTP NAT work again (as in 1.3b4 and before), but that would probably only be a workaround (assuming that the reason for these changes is valid)...
« Reply #2 on: August 04, 2009, 23:25:30 »
Manuel Kasper
Administrator 		*****
Posts: 364
For the record - I have just committed a kernel patch that avoids this problem by making ipnat allow RDR translations even if there is already a MAP translation for the same port (but not if there's already an RDR - this is probably the way that ipnat kernel change was intended in the first place).

It will be in 1.3b17 and will hopefully fix problems with SIP communication when there is an inbound NAT rule for SIP.
 
Pages: [1]
 
 
Powered by SMF 1.1.20 | SMF © 2013, Simple Machines