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 the

gateway/DNS addresses as 10.2.1.1 and 10.1.1.1 respectively.

In VMware, start the new team wizard File > New >

Team…


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 (64×2 + 128×2); 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 recommend

placing 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 on

each gateway.

The nmproxy configuration file is /etc/nmproxy.conf. Configuration

is not difficult–we simply need to specify the local network, and map the

default 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 > Removable


Devices > 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 and

there 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 the

second 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 a

dead 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

feature.

If any readers manage to get nmproxy running, or have done

so in the past, please let me know!