NAT routers ( these are mostly used to provide access to the internet for a LAN via a single routable IP address)
	Proxy servers (often these are used in the same situation as NATs but sometimes have extensive firewall functions)
	LAN Firewalls - usually these provide some sort of NAT function in addition to extensive LAN protection features
	Personal firewall products  ( Black Ice Defender, Zone Alarm, Norton's NIS (formerly AtGaurd), McAfee 's Conseal)

	no incoming NetMeeting calls (for MSN Messenger this means that you cannot use the invite function)
	outgoing calls will allow audio/video transmission but no audio/video will be received.

From:  "Thomas DeBellis" 
Date:  Fri Oct 25, 2002  5:14 pm
Subject:  RE: [NetMeeting] NetMeeting on XP behind a Linksys BEFSR41 router
- moving off topic

Geoff,

I've been following this thread for awhile and I thought that I might
chime in with what I know. Since, by far, the majority of problems
reported with Netmeeting are actually router related, I'm going to
assume that this post won't be considered off topic and that I won't
get yelled at.

It *IS* rather long, however, and there is a lot of technical detail
here to digest which will not make much sense to the typical consumer
or casual user who (rightfully) "just wants it to work" and doesn't
understand why it doesn't. If that is the case, then maybe they can
just hand this post to some more technical person and have things
figured out for them.

As background, I am a consultant, specializing in security issues and
I have both DSL and Cable broadband services at home because I need to
be highly available to support remote customer sites. I use
netmeeting to talk to my clients. This has the benefits of avoiding
costly phone calls, being able to remotely show them what to do on
their desktop and being able to see, by the look on their faces,
whether they get the explanation or not. Many clients do not want to
admit that they have no idea of what is going on and will say "Yes"
when they really mean "No". Seeing facial expressions is invaluable.

I am running two LinkSys routers, one is a BEFSR41 (like what you and
Brian have) and the other is a BEFVP41. The difference is that the
latter is an encrypting VPN router (more on this later). These are
wonderful devices, but being marketed to the consumer, technical
details are often lacking as to what is going on. It is true that
detailed information on the LinkSys website is quite sparse. The best
place to find out about the tweaky little details is to go to
www.dslreports.com and surf the LinkSys forum. There are some people
there that do nothing but hack these routers and you can learn an
awful lot (I did).

Brian is correct that the router will function as an H.323 proxy, but
ONLY on an outgoing call. You can observe this by doing two things.
First, go to the Log tab, click the Enable Access log radio button and
then set the logging address to 255 so that the SNMP log messages are
broadcast to the entire LAN subnet. Don't forget to click Apply.

Second, the stardard reporting tools included in the router web
interface will not get you the information that you need. You want to
get a free product called SNMP Trap Watcher that will log all messages
coming out of the router. This can be downloaded for free by going to
the BTT Software site at http://www.bttsoftware.co.uk/.

Once you are running SNMP trap, you want to filter out a number of
messages (BFREE), but I will ignore this detail for now. If you make
an outgoing call, you will see that the router actually knows that
H.323 is in use and will allow the outgoing connection. Pretty cool,
eh?

The gotcha is that the target machine being called must NOT be behind
a firewall or NAT device *OR* be on a H.323 gateway that is NOT behind
a firewall or NAT device *OR* the router itself must have some sort of
H.323 knowledge (more on this below #2). This is almost NEVER the
case and for good reason.

Given the amount of virii, script kiddies and other advertising
lossage, you really have to be nuts NOT to have a consumer system
(i.e., Windows) behind a NAT firewall these days. So, as a result,
the Netmeeting calls will *always* fail. What to do? Thus far, I
have found four solutions, here they are with associated drawbacks:

1) Have both parties put their machines in the router DMZ. This is
usually the easiest and most direct way to explain to somebody.
Note that the documentation for the router says that the specified
hosts must not be DHCP but have hardwired IP addresses. This is
not true.

I have local DHCP hosts that I have put in the DMZ; it works fine,
but you will have problems if the local host IP address changes.
These typically won't if you don't reboot. My hosts stay up an
average of two to three months between reboots (I use UPS's), so
this isn't a problem for me.

The benefits of using the DMZ is that you can get an unsolicated
incoming call, if you keep netmeeting running. This can be nice
because the person calling you doen't have to contact you first
through some other channel to be ready to get the call. This is
important if you are doing support work, for example. However,
you can't have more than one person at the same time on the local
LANs making a call.

The real problem is that the host that you are running in the DMZ
is now running around on the Internet with its electronic pants
down, so to speak. Remember what I said about being nuts? Well,
for the length of time that you are in the DMZ, the bad guys can
get at you and believe me, they are looking ALL THE TIME.

You must carefully close a number of ports and it isn't directly
obvious (or even possible) how to do this on some versions of
Windows. You have to load NetBEUI and the Microsoft loopback
device and then make sure that your WINS Client is bound to only
that. If you have XP, you also have to go through the hassle of
making it talk to these systems because NETBEUI isn't included by
default.

Even the H.323 Gateway mentioned previously has this EXACT SAME
RISK: you must put the (Windows) system running the gateway in the
DMZ and worry about securing that. Sounds risky and like a
hassle? It is to me. I *NEVER* use this unless I absolutely
*have* to take a call from somebody who can't do it any other way.
I try really hard to use #2 below before I do this.

2) Use the port triggering mechanism of the LinkSys router to only
allow ports to be opened on an incoming call. This has the
advantage of allowing you to get incoming calls without being in
the DMZ, but it is not quite completely secure or convenient. To
do this, you must have some idea of the ports that Netmeeting uses
and for what reason. For brevity (?), I won't explain these 
further, but they are:

Service Type Port or Port Range

Internet Locator Server TCP 389 
User Location Server TCP 522 
T120 TCP 1503 
H.323 Call Setup TCP 1720 
Audio Call Control TCP 1731 
H.323 call control TCP (*Dynamic) 1024-65535
H.323 streaming UDP (*Dynamic) 1024-65535

It is these dynamic ports at the bottom of the list that are the
problem. H.323 negotiates channels to stream the audio and video
data. Since the router really has no idea of what TCP/UDP ports
these channels will be on, it can't forward them, a priori. This
is why Netmeeting will not work behind a NAT device.

However, you can use the LinkSys port triggering feature (as what
I think of as a 'hack') to get things to work. To set up the
appropriate triggering, you want to go to the advanced tab of your
router and select forwarding. Once you do this, you must then
select port triggering and fill in the above values, viz:

Application Trigger Incoming
Name Port Range Port Range

1. Netmeeting 389-389 389-389
2. Netmeeting 522-522 522-522
3. Netmeeting 1503-1503 1503-1503
4. Netmeeting 1720-1720 1720-1720
5. Netmeeting 1731-1731 1731-1731
6. Netmeeting 1024-65335 1024-65335

As always, don't for get to click Apply or your changes may be
lost if you switch to another page. The observant reader (are
there any still reading this?) will now notice that I haven't said
ANYTHING about an IP address for a machine to get the calls to,
yet. It isn't necessary. The way this works is that when YOU
make an OUTGOING call, use of ANY of these ports will cause them
ALL to be opened and an incoming request on any of them to be
forwarded to your computer.

So what happens is that you call the other person and then that
person calls you. Both calls fail. Now that all the ports are
open and properly forwarded, the next call will succeed, but you
better be quick before they get closed. More details on this can
be found at http://users2.ev1.net/~wufdog/Linky/NetMeeting.htm and
http://www.dslreports.com/forum/remark,1020195;root=equip,16;mode=flat

The benefits of this are that now any host on your local LAN can
make an outgoing call, thus setting up things to get a remote
call, for a time. However, I don't know how long the ports stay
open and that's part of the problem. The router does not know
which port is the 'primary' port. So, outgoing activity on ANY of
them will cause them all to be triggered.

If you have somebody else on your LAN using any of these port
ranges, then they may trigger the port triggering to their machine
and you may find that your call will drop. As above, you can't
have more than one person at a time on the local LANs make a call.

But the real problem I have is that having such a *huge* range of
port addresses triggered is a potential security issue. Once
you've triggered (and hence opened one port), you have opened well
over 60,000 other ports and they are now all coming to your
machine. Who knows what is listening on these ports?? Script
kiddies doing port scanning (and they do this all the time) can
now poke around on any port that you have open in this range.
They'll find out which ports are open for you... This should not
make you feel comfortable.

Actually, it's not quite as bad as that; the major security loop
holes in Windows are ports 135, 137, 138 and 139 which support
NetBIOS file transfer, RPC and Windows Messenger service. These
are clearly not triggered by the above. However, it's probably a
good idea to filter these ports, to prevent anybody in your subnet
from publishing or accessing remote shares and doing other things.
I have them filtered. Go to Advanced -> Filters page to do this.
Note, you will no longer be able to publish a share on the
Internet. That's a good thing most of the time.

Another drawback of this approach is that you can't get an
unsolicated incoming call, even if you keep netmeeting running.
That is because port triggering works (and can only work) when you
(usually both of you) initiate an outgoing call from your LAN to
the WAN. So, the person calling you must contact you first
through some other channel to be ready to get the call. This
could be email in which you schedule a time, but is typically a
phone call.

Finally, the router supports something called StateFul Packet
Inspection that will allow it to crack packets to figure out what
to open, but I don't know anything more about it as it is still in
beta.

3) Use of Point to Point Tunneling Protocol (PPTP). You may have
noticed IPsec Pass Through and PPTP Pass Through listed on the
router advanced -> filters page. These allow you to set up a host
to host virtual private network if you enable them.

I won't go into detail here, but you can set up *any* Windows
machine from 98 on up as a VPN client and any machine from NT up
as a VPN server. The client machine sets up a virtual private
network connection to the IP address of the remote WAN. The
remote router is then set to route port 1723 to the machine doing
the serving which has an incoming connection configured.

The advantages here are that once you've made the connection, your
client machine now shows up as a real IP host in the target LAN.
Netmeeting calls work trivially because there is no NAT getting in
the way; you are literally behind the firewall and look local.
You can call anybody on the LAN and they can call you. Note that
you have to set it up "the other way around" if you want the
remote person to be able to call you.

With this solution, you can now make an unsolicted call whenever
you want and not have to call somebody beforehand (again, assuming
that they are running netmeeting). You just click on the remote
connection and after some bit banging, you are on the remote LAN
with a remote IP address and can make the call.

NETBEUI is also forwarded, so you show up in the local workgroup.
This enables you to securely transfer data. It also looks 'cute'
to customers because they can now see that you are actually
there. You can do a "net send <host>" to bother people.

Both the video and audio of the call are now encrypted which can
be important if you are worried about being HIPAA conformant or
are just plain paranoid. No ports are opened up besides 1723
which enforces security. This is my preferred method, it's cheap
and it works (mostly).

There *are* a number of problems. The Microsoft PPTP product is 
not robust in a couple of areas. The VPN link can go down after 
a while for no apparent reason (even if you have a ping -t 
running in the background).

There are routing issues, also. Once you make the VPN call,
Windows will assume that the initiating client wants to route ALL
IP traffic over the VPN link. This means that if you are
listening to a net radio station, that traffic is now going to get
routed to the remote site which has to figure out what to do with
it. This can be a problem if the remote router blocks the traffic
or (more typically) doesn't have the bandwidth for the radio and
your netmeeting call.

I have also had to reboot machines in order to unstick them, which
can be a problem if the machine is remote. It's another phone
call... The routing tables can get glitches (see previous
paragraph), but I can usually fix these by hand tweaking things
with the route command.

If you use DHCP, the remote VPN server can sometimes get mixed up
and hand out the wrong IP address causing conflicts (and hence
loss of service). The longer you keep the system up, the more
likely this is.

You can NOT configure a system with dual NICs to get an incoming
VPN call without Windows losing track of one of the NICs. This is
a real problem if you have highly available machines (like three
of mine); none of them can be servers. It's a 'documented'
issue. Who knows when it will be fixed...

Security flaws have been found in a number of areas dealing with
authentication and buffer overflow. Since you are doing
encryption, you are going to use more network bandwidth and the
system doing the encryption will see more load. I have an
encrypting board on some of my slower systems to handle that
issue.

It is possible that some regulatory agencies, comercial agreements
and/or governmental policy will forbid encrypted traffic,
particularly if you are going International.

The main problem is that the user experience is no longer at the
consumer level. There are more things to click and when things go
wrong (as they frequently will), you'll need a technical person
around to kick the bits. That's a problem if you are trying to
support or talk to a remote non-technical person.

4) Use an encrypting router. Remember the BEFVP41 I mentioned above?
It can set up a VPN for you and route traffic between the two
subnets. You go to the VPN page and set up a tunnel to your
remote user and they do the same. Click connect and you are all
done. It took me about 10 minutes to set all this up. What are
the benefits? Because the router itself is now handling the
traffic and connections:

a) Zero configuration changes to make on your local systems.
b) It works for ANY kind of local host (Linux, Tops-20, etc.)
and ANY kind of port: Games, ftp, Telnet, WINS all work.
c) The router offloads the encryption, so your slow hosts don't
run out of gas.
d) The router worries about keeping the VPN up and it seems to do
a great job. I have had zero (yes, that's "0") downtime to my
remote sites since I have started using the BEFVP41.
e) Great security; everybody is behind a firewall.
f) Netmeeting calls are encrypted over the Internet.
g) Unsolicted calls are now allowed in BOTH directions.
h) Highly available systems continue to work.
i) Windows 2000 and Windows XP have built in IPsec clients that
will allow you to use this from another site, even if it
doesn't have an encrypting router providing it allows IPsec to
go through unmolested on port 500.
j) NO CHANGES IN THE TYPICAL END USER EXPERIENCE!!!

It should be obvious that I *love* this router. I can't wait to
get rid of my other BEFSR41 router. However, there are some minor
concerns that you should be aware of.

a) There needs to be at least one (and better) two routers.
b) Cost: a BEFVP41 is at about twice the price of a BEFSR41. I
have seen the BEFSR41 go for about $60 US and the BEFVP41 list
for about $115 US. This cost issue is what kept us using #3
until we got fed up with it.
c) Because you are using encryption, you will use (some) more
bandwidth. This could be a problem on capped cable lines or
DSL lines with limited upload bandwidth
d) You do need to have some technical chops to get it set up (but
you can basically forget about it after that).
e) If you want it up all the time, you will need a UPS.
f) It only makes sense for people that you call a lot. For the
arbitrary call to the arbitrary person, it's a hassle to have
to set up and tear down all those tunnels. In our case, it
has *eliminated* long distance calls to remote sites. This
could help offset the cost of the router.
h) The VPN'ed subnets now have *complete* access to each other
(i.e., there is no firewall protecting hosts on one site from
accesses by hosts on another). You may have to take steps to
secure hosts if you have people poking around (like students,
children or curious adults). This is a real problem for
Windows 98.
i) It is possible that some regulatory agencies, commercial 
agreements and/or governmental policy will forbid encrypted
traffic, particularly if you are going International.
j) Once it's up and people realize the call is free, you sure do
get bugged a lot!

Anyway, I hope that I've been of some help. The point that I want to
make here is that there should be less netmeeting banging. Netmeeting
usually works just great (when it works) and you can get Macintosh
clients. Unfortunately, for efficiency reasons, it needs to negotiate
seperate ports and these can get you into trouble when you are running
NAT (which nearly all people do).