| Newsgroups |
gmane.comp.security.firewalls.m0n0wall |
| Message-ID |
<[email protected]> |
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 [email protected]
Date: Wed, 14 Dec 2011 14:06:00 -0500
To: [email protected]
Subject: Re: [m0n0wall] Disabling NAT
On Wed, Dec 14, 2011 at 11:11 AM, [email protected]
<[email protected]>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 * * 192.168.102.2 5060 iChat (SIP)
TCP/UDP * * 192.168.102.2 5190 iChat (file
transfer)
TCP * * 192.168.102.2 5220 iChat (XMPP/Jabber)
TCP * * 192.168.102.2 5222 - 5223 iChat (XMPP/Jabber)
TCP * * 192.168.102.2 5297 iChat (local
traffic, Bonjour)
TCP/UDP * * 192.168.102.2 5298 iChat (local
traffic, Bonjour)
UDP * * 192.168.102.2 5353 iChat (MDNS)
UDP * * 192.168.102.2 5678 iChat (SNATMAP)
UDP * * 192.168.102.2 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
enabled:
Interface Source Destination Target Description
WAN 127.0.0.0/8 * * Normal outbound
mapping for localhost
WAN 192.168.100.0/24 * * Normal outbound
mapping for LAN/WLAN bridge
WAN 192.168.101.0/24 * * Normal outbound
mapping for PPTP
WAN 192.168.102.2/32 * * (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
interfaces:
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:
http://www.google.ca/search?q=ocs+nat
this link looks promising:
http://social.technet.microsoft.com/Forums/da-DK/ocsedge/thread/f93ddf4e-74a
7-40b0-a358-
79bd608636dd
cheers,
jj
--------------------------------------------------------------------
mail2web - Check your email from the web at
http://link.mail2web.com/mail2web