[ previous ] [ next ] [ threads ]
 From:  "lextre at trelex dot co dot uk" <lextre at trelex dot co dot uk>
 To:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] Disabling NAT
 Date:  Thu, 15 Dec 2011 08:09:44 -0500
Thanks guys for the replies. The suggestions will certainly help me should
I need to do some more 
detailed port mappings and rules creation. I'm still awaiting a response
from the other organisation 
regarding the exact requirements and will take it from there. I have
another question though - is it 
actually possible for an ISP provided router to run some form of NAT on the
public ip and if so in what 
scenarios would this be required? Eg, we have a router provided by our ISP
with a number of static ip 
addresses. Our m0n0wall is our firewall/router acting as the gateway for
the LAN clients.

workstations -> m0nowall -> Provider's router -> Internet

So, in the above simple example our internal LAN clients connect to the
internet and each of the 
workstation's ip address will be translated into the single public ip of
the WAN interface. As our ISP has 
provided us with a pool of ip addresses to use is it possible that the
ISP's router could perform some 
form of NAT on the address coming from the WAN address of m0n0wall?

I know this is NOT happening in our case I was just wondering if their is
equipment out there which may 
do this and what would be the purpose/benfit of doing so.

Thanks again.

Original Message:
From: Joey Morin joeymorin at alumni dot uwaterloo dot ca
Date: Wed, 14 Dec 2011 14:06:00 -0500
To: m0n0wall at lists dot m0n0 dot ch
Subject: Re: [m0n0wall] Disabling NAT

On Wed, Dec 14, 2011 at 11:11 AM, lextre at trelex dot co dot uk
<lextre at trelex dot co dot uk>wrote:

> As for the bigger picture I'll try to describe the problem. We are a
> relatively small organisation of around
> 100 staff spread across two offices employing m0n0wall as the
> firewall/router in both locations. We had
> an IPSEC vpn setup within m0n0wall to connect both offices and everything
> had been working fine. Now
> we are partnered with a much larger organisation and they want to improve
> communication with us. As
> a result they want us to use OCS (communicator) and some proprietary video
> conferencing software
> which, apparently, cannot function via a NAT'ed router. So what they have
> asked us is to disable our vpn
> connection and make sure that there is no NAT running on our routers.

i had a similar problem with getting an iChat installation working from
behind a m0n0wall.  i don't know about ocs, but iChat uses a technique
called STUN that has issues with NAT as well, although it is not entirely
incompatible.  the solution was to:

1) create inbound NAT and firewall rules to forward appropriate ports to
the internal machine that needed to push A/V back and forth to the other
site.  note that not all of these forwards were necessary to enable the
desired iChat functionality, but this is a complete list of possible
ports.  if i remember, only 5060 and 16384-16403 were necessary for my
case.  after experimentation i disabled the others to minimize exposure:

Proto     Source  Port  Destination     Port            Description
UDP       *       *   5060            iChat (SIP)
TCP/UDP   *       *   5190            iChat (file
TCP       *       *   5220            iChat (XMPP/Jabber)
TCP       *       *   5222 - 5223     iChat (XMPP/Jabber)
TCP       *       *   5297            iChat (local
traffic, Bonjour)
TCP/UDP   *       *   5298            iChat (local
traffic, Bonjour)
UDP       *       *   5353            iChat (MDNS)
UDP       *       *   5678            iChat (SNATMAP)
UDP       *       *   16384 - 16403   iChat (RTP/RTCP)

2) create and enable advanced outbound NAT rules to prevent m0n0wall from
randomizing the source port of outbound connections, as randomized source
ports breaks STUN (in my case, the target internal machine was alone on a
separate internal interface, and i also had PPTP server active).  note that
the important rule is the last one.  it disables the source port
randomization.  the first three rules explicitly enable source NAT on my
other interfaces.  this is necessary because the m0n0wall will no longer
automatically NAT outbound connections when advanced outbound NAT is

Interface   Source            Destination   Target          Description
WAN       *             *               Normal outbound
mapping for localhost
WAN  *             *               Normal outbound
mapping for LAN/WLAN bridge
WAN  *             *               Normal outbound
mapping for PPTP
WAN  *             * (no portmap)  No port
remapping for DMZ outbound NAT
                                                            (For machine
with iChat in DMZ.
                                                            Must be
combined with "Outbound NAT port
                                                            range" of
17000-65535 in "System/Advanced")

3) modify 'Outbound NAT port range' in the 'Firewall' section of the
'System/Advanced' page to avoid the range of ports that have been forwarded
via inbound NAT.  this is necessary to ensure that none of the forwarded
ports get randomly assigned to NATed outbound connections from the other

Outbound NAT port range:    17000 - 65535
                            This setting controls the range from
                            which ports are randomly picked for
                            outbound NAT. Do not change this unless
                            you know exactly what you're doing.

note that if your internal machine is not on it's own interface, you will
need a slightly different outbound NAT rule-set.  ...and none of this may
be of any help for OCS.  i am not familiar with it.  you may want to do a
search for ocs and nat:

this link looks promising:


mail2web - Check your email from the web at