News: This forum is now permanently frozen.
Pages: [1]
Topic: Possible inbound NAT bug affecting SIP clients behind 1.3b firewalls  (Read 6352 times)
« on: March 23, 2008, 14:11:56 »
GaijinLife *
Posts: 4

I upgraded several m0n0wall 1.233 based firewalls to the latest 1.3b10 build and noticed inbound SIP invite messages being dropped even though proper NAT rules are in place. It doesn't seem to affect all VOSPs, just those using SIPpy as their back-to-back user agent.

Rebuilding the m0n0wall 1.3b10 configuration from scratch doesn't fix the problem however reverting to 1.233 does.

Did anyone else experience similar issues with the 1.3 beta builds?

Thanks!
« Reply #1 on: March 24, 2008, 12:23:29 »
GaijinLife *
Posts: 4

Following more testing I narrowed down the incompatibilty with the Sippy implementation used by PortaSIP: http://portaone.com/products/portasip/sipoverview/

Forwarded inbound INVITE packets get dropped yet don't get logged in either the firewall log or the fw rule log.

Can any m0n0wall gurus help debug this problem?!

Thanks!
« Reply #2 on: March 24, 2008, 14:52:41 »
mwiget *
Posts: 38

The only problem I had in the past with SIP was related to packets getting fragmented. This happened with SIP packets containing long SDP information (INVITE and response to it). Turning on 'Allow fragmented IP packets' in the LAN Firewall rule let them through.

Maybe PortaSIP has an unusally long invite too? My case was related to a long list of video codecs  that didn't fit into a single UDP packet.

« Reply #3 on: March 24, 2008, 16:24:28 »
GaijinLife *
Posts: 4

PortaSIP does indeed have unusually long SDP streams, however this wouldn't explain why it works fine with 1.233 and doesn't with 1.3b10?!

As part of my testing I did allow fragmented packets through the rule without any success.
« Reply #4 on: March 28, 2008, 23:23:28 »
GaijinLife *
Posts: 4

After testing all 1.3b builds we determined the bug was introduced in build 1.3b5.

I wonder if the introduction of siproxd in the same build is just a coincidence or the actual cause of the problem.
« Reply #5 on: November 28, 2009, 18:45:58 »
Manuel Kasper
Administrator
*****
Posts: 364

This should be fixed by the NAT changes in 1.3b17:

Quote
fixed a problem with ipnat refusing to create new RDR translation entries in the NAT table if a MAP entry exists for the same port, even though that check is probably only meant to check for existing RDR entries. This fixes issues with SIP communication when there is an inbound NAT mapping for port 5060. (see also http://marc.info/?l=ipfilter&m=121749272404107&w=2)
 
Pages: [1]
 
 
Powered by SMF 1.1.20 | SMF © 2013, Simple Machines