Continuing from last week, we now have two OpenBSD gateways
which are able to talk to each other. In this final instalment, we will use the
team feature of VMware to group each Gateway with a Windows XP machine, and then
try to initiate a call from one network to the other.
I am assuming that you have already installed your Windows
XP machines and have given them IP addresses 10.2.1.2 and 10.1.1.2 with thegateway/DNS addresses as 10.2.1.1 and 10.1.1.1 respectively.
In VMware, start the new team wizard File > New >
Add the Virtual Machines as above, then move on and create three LAN segments:
Now configure the Virtual Machines to connect to those LAN segments as follows:
Finish the wizard and we will now look at a more interesting
feature. Open the team Settings and continue to the LAN Segments tab. We
can see our three LAN segments earlier defined: LAN1 is our 'Internet' segment,
so we can rename it. We can also have this segment emulate a 1.5-Mb leased line
with 1% packet loss (now you are seeing that this can be a great tool for
testing and emulating various network conditions). The other two segments can
be renamed Internal LAN1 and 2 or left as they are.
The group can now be started. This is where you will notice
a slowdown if your host machine does not have a good helping of RAM. Our setup
here is using 384 MB of RAM (64x2 + 128x2); you will have probably noticed in
the preferences that you don't need to have this all in physical RAM. You can
have some swapped to disk; however, this is very slow. I would recommendplacing all of this in physical RAM.
The first thing to do once all machines are up is to ping
the opposite counterpart. From Windows XP A ping Windows XP B and
vice versa. This should work without problems (turn off the Windows firewall;
the BSD gateway provides the firewall), but if you do have trouble, check the
firewall rules in /etc/pf.conf oneach gateway.
The nmproxy configuration file is /etc/nmproxy.conf. Configuration
is not difficult—we simply need to specify the local network, and map thedefault forward rule (full details here).
I used two USB Webcams—one connected to each XP machine. Connecting
the camera to your VM is simple: Give the desired machine focus, then plug the
USB camera into your host. VMware should conne ct automatically to the USB
device and bridge it to the VM. If not, you can go to VM > RemovableDevices > USB Devices > (your webcam) to connect it manually.
Within Windows XP we now need to start Netmeeting. Most
people don't realise that this is still installed by default, as there are no
links created. Type conf.exe in your Run dialogue andthere it is!
Once this is running we can try to initiate a call from one
machine to the other. Type the IP address of the second machine in your call
box and hit the telephone button. The counterpart Netmeeting instance on thesecond machine should ring!!!
This is where things become a little disappointing; the
second machine did receive the call, however, when pickup was selected, the
call did not connect. The first machine didn't even recognise that the call was
accepted. I checked all of the settings in both pf.conf and nmproxy.conf
with no obvious errors. I then also use the pflog device and tcpdump
to see if any connections were being blocked by the firewall, but unfortunately
this was not the case. It seems that nmproxy collects the connections but does
not then initiate the audio/video streams. I emailed the author who was not
helpful in the slightest. After posting questions on a few popular networking
forums, it seemed that nobody had successfully managed to get this working.
After that I decided that it's not worth wasting more time trying to flog adead donkey, so I'm looking at alternative gatekeeper solutions.
I hope this series of posts has been useful to people. We
haven't found a great H.323 video proxy, but we have gone over basic
installation and configuration of OpenBSD as well as introducing the use of
VMware to speed up testing and troubleshooting. In total, the practical
implementation of this test environment took me about 3-4 hours. This would
have been a little less if I had used a pre-prepared generic install of OpenBSD
to start from (as I did with the XP workstation VMs). I personally think this
is much more sensible than trying out untested code in a live environment; it's
also much faster than building a physical test environment due to the cloning
If any readers manage to get nmproxy running, or have doneso in the past, please let me know!