Fernando Alvarez schrieb:
Hi all,
I've trying to configure an OpenBSD box to allow PF to pass
video-conference traffic through a NATed network without success.
I tried to setup the most basic configuration in order to find out where
the problem could be. Last test I did, I configured an OpenBSD box with
two network interfaces ($if_int and $if_ext) and PF enabled. NAT is done
on $if_ext, and all the traffic is redirected from LAN to the videoconf
PC.
[VideoConf PC]----[OpenBSD box]-------------LAN
192.168.10.2/24 .10 172.22.1.200/16
-> When I try to call (using Netmeeting and other H.323 software) from
the VideoconfPC to a PC, the other party answers and audio flows only in
one direction: The PC in the LAN hears what I say, but nothing is heard
in the VideoConf PC.
<- When I try to call from the LAN to the VideoConf PC (using OBSD's
external IP as address) Netmeeting says the other party is not
responding.
Tcpdump does not show any blocked packet and the rdr seems to work
properly. As you can see bellow, my pf.conf is very simple:
Any ideas? What do you think I've misconfigured?
pf.conf
-------------------------
# interfaces
if_ext = "pcn0"
if_int = "pcn1"
videoconf = 192.168.10.2
nat log on $if_ext from $videoconf to any -> $if_ext
rdr log on $if_ext -> $videoconf
pass log all
--------------------------
Thanks in advance,
Fernando Alvarez
Hi Fernando,
you could google for "H.323 over NAT" and find tons of hits, none of
them giving you an easy answer. The problem is, that the nat device
rewrites the source ip address in the tcp-header, while it does not
inspect the H.323 packet's Protocol data unit which also contains the
source ip address. This is most likely irritating your apps.
Several workarounds exist:
- use H.323 aware firewall
- stick with a provider that lets you use his session border controller
- check your apps if you could propably go with public stun servers
- give gnu gatekeeper a try, which is in ports
http://www.gnugk.org/h323-proxy.html
- ... (i.e. put netmeeting in a dmz)
Regards,
Dorian
