Hi.

I'm having a confusing time with a network setup... this is using pf
on OpenBSD 3.8, generic 386 kernel

VOIP Phones (public 20.0.0.x/24)
   mixed with
Office PCs (private 192.168.1.x/24)
     |||
     \V/
  HW switch
      |
  $int_if OpenBSD router (192.168.1. 1)
           |   +--- $ext_if for "PCs ISP" (configured via dhclient)
           +--- $voip_if for "Phone ISP" (either no addy or 20.0.0.
225, route to 20.0.0. 1)

(most public numbers herein changed)

 There's an internal network with voice-over-IP phones and PCs. The
phones have publicly routable addresses, and for them, the OpenBSD
router should act like an addressless bridge. The router also all
assigns PCs private addresses via DHCP, and gives them access to the
big bad internet via pf's NAT.

Here's my pf.conf (for the moment:)

# Symbolic names for our NICs
# public_if is the public interface the computers use. It has an IP address.
# bridge_if is a bridge that passes traffic, expected to have no IP address.

# If these change also edit /etc/hostname.* and /etc/bridgename.*
int_if="fxp0"
bridge_if="ep1"
public_if="sk0"

# pc_net is for our computers, voip_net is for our phones
pc_net="192.168.1.0/24"
table <voip_net> persist file "/etc/voip_net"

# nat: packets going out through $public_if with source address $pc_net will
# get translated as coming from the dynamic address of $public_if, creating
# state for such packets- so reply packets will be redirected to the
# internal address.
nat on $public_if from $pc_net to any -> ($public_if)

# Use internal FTP proxy
rdr pass on $int_if proto tcp from $pc_net to port ftp -> 127.0.0.1 port 8021

# pass all traffic
pass quick on lo
pass all

===
other files of note:
hostname.ep1:
inet 20.0.0.225 255.255.255.0 216.27.176.255 description "VOIP uplink"

hostname.fxp0:
inet 192.168.1.1 255.255.255.0 192.168.1.255 description "Private
subnet interface

hostname.sk0:
#  uplink for office pc traffic
dhcp

bridgename.bridge0:
add fxp0 add ep1
up

===

Here's what happens:

All the PCs can talk to the outside world AOK- until someone picks up
a phone.  The phones work AOK all the time, but once people start
using them, the PCs stop working intermittantly. I set up machines to
ping the outside world endlessly, and see them get replies and then
not, and then get them again, for no apparent reason.

Here's what tcpdump shows me on the internal office interface:
# tcpdump -i fxp0 icmp and net 192.168.1.0/24
tcpdump: listening on fxp0, link-type EN10MB
13:36:05.857670 192.168.1.99 > knowngoodhost.com: icmp: echo request
13:36:06.509968 192.168.1.24 > knowngoodhost.com: icmp: echo request
13:36:06.858996 192.168.1.99 > knowngoodhost.com: icmp: echo request
13:36:06.864202 192.168.1.22 > knowngoodhost.com: icmp: echo request

requests coming in from my three test office PCs, no replies.

What's the traffic on bridge0?
# tcpdump -ni bridge0 icmp and net 192.168.1.0/24
tcpdump: WARNING: bridge0: no IPv4 address assigned
tcpdump: listening on bridge0, link-type EN10MB
13:39:40.632294 192.168.1.99 > knowngoodhost.com: icmp: echo request
13:39:41.008804 192.168.1.24 > knowngoodhost.com: icmp: echo request
13:39:41.362058 192.168.1.22 > knowngoodhost.com: icmp: echo request

Hmm, that traffic used to be nat'ed out of sk0, now it's showing up on
the bridge.

Retry to be sure... I run /etc/netstart to go back to a more
"pristine" state- ok I see all three test PC's are getting responses
from their pings. tcpdump shows
bridge0 has no traffic from $pc_net. That's what I like.

Now I'll pick up a VOIP phone- I make some phone calls, good, all
three machines keep pinging, good.  I interrupt one ping, wait for the
state to expire (check with pfctl -s state), try pinging again-
request times out. tcpdump shows my 192.168.1.x traffic on bridge0
again.

My understanding was that the kernal would grab the 192.168.1.x
traffic coming into $int_if (aka fxp0)- addressed as 192.168.1.1-
before the bridge got it. That seems to be the case before the bridge
is in use, but once the bridge sees traffic, it grabs the 192.168.1.x
packets as well.

How can I prevent that?

thanks for your time

-y

Reply via email to