NAT rewriting port, breaking the rules

[Michael]

Hello list,

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
used.

The problem is that m0n0wall's NAT logic does indeed rewrite the
port number on some packets. This causes problems at the receiving
end.

Why is m0n0wall rewriting the port number of packets when 'Disable
port mapping' is enabled? Is it because of something in the Traffic
shaper maybe?

Regards,
Michael

[Chris Buechler]

Post by Michael
Hello list,
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
used.
The problem is that m0n0wall's NAT logic does indeed rewrite the
port number on some packets. This causes problems at the receiving
end.
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.

[Michael]

Hello Chris,

Post by Chris Buechler

Post by Michael
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
used.
The problem is that m0n0wall's NAT logic does indeed rewrite the
port number on some packets. This causes problems at the receiving
end.
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.

Regards,
Michael