On Thurs., Jan 27, 2011, Chris BUECHLER wrote:
>On Thu, Jan 27, 2011 at 2:51 PM, Michael wrote:
>> Has anyone else seen this behaviour? To provide a SIP proxy with
>> the help in needs in overcoming NAT for telephony applications,
>> m0n0wall can be configured to 'Disable port mapping' in the tab
>> Firewall/NAT/Outbound entries.
>> When I check 'Disable port mapping', almost all packets leaving
>> the NAT have the same port number as that which the sending devices
>> The problem is that m0n0wall's NAT logic does indeed rewrite the
>> port number on some packets. This causes problems at the receiving
>> Why is m0n0wall rewriting the port number of packets when 'Disable
>> port mapping' is enabled?
>Did you reset states after changing that? Otherwise the connections
>that were already active will stay that way as long as they're
>active, which will be forever with SIP.
Your idea seems reasonable, however in my case 'Disable port
mapping' was enabled since the last reboot I think. I'll reset
the firewall states now just to be sure, test again, and let
you know the results.
By the way, wouldn't it be best to always choose a single port
(re)mapping regardless of the 'Disable port mapping' setting?
Otherwise m0n0wall wreaks havoc with NAT logic expecting traffic
from a nonchanging TCP/UDP port number. This is the case for
m0n0wall in particular, because it doesn't seem to support
'full cone' NAT logic at all.
Or is there some way to control the NAT tables that I haven't found?
It doesn't even seem to be possible to inspect the NAT table, which
is not the same thing as 'Diagnostics/Firewall states'. I can make a
firewall entry to let traffic through the WAN, but if there's no
associated NAT table entry for the traffic in question then the
traffic is silently ignored right? That's disturbing.