From: Gary Ikonen (fecundspeakeasy.net)
Date: Tue Aug 24 2004 - 16:49:26 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

I'm using OpenBSD 3.5 and am now able to filter packets from one TCP
port off a bridge. The trick was to use an explicit route- the
redirect rewrote the destination IP address and port just fine, but it
had the wrong destination MAC address.

Questions-
1. This setup requires two rules in pf.conf- a redirect, and then a
"pass" rule whose purpose is to add the "route-to". Can the route-to
be inserted into the "rdr" rule?
2. I expected the "rdr" rule to update the routing of the packet. Why
did I have to add the rule with the "route-to" clause in the first
place?

The setup-

     +--Internet--+
           |
           |
           v $ext_if
      +--BSD FW--+
           ^ $int_if 10.0.0.1
           |
   +-----switch-----+
   |BSD |BSD | WinPC
+-o.2-+ +-o.3-+ +-x.217-+

There's a windows machine that has the external address. Its traffic
is filtered through an OpenBSD firewall. I have a couple more BSD
machines in the house that all talk on a private network.

The two interfaces $ext_if and $int_if are bridged (on bridge0)

One of the internal machines, o.2 at 10.0.0.2, is going to be running
smptd, and needs to be accessable from the outside world. Here are the
entries I added to pf.conf so the outside world can connect to the
x.217 address, and really be talking to o.2 inside:

rdr on $ext_if proto tcp to $ext_addr port smtp tag diverted -> $inner_server port smtp
pass in log route-to $int_if proto tcp to any flags S/SA keep state tagged diverted

where $ext_if and $int_if are the interface name for the firewall's
external and internal interfaces, and $inner_server=10.0.0.2.

Having to add the route-to took me hours to figure out. Before then,
I was seeing the following on $int_if (using tcpdump, making requests
from an outside client)-

Aug 24 14:29:39.291409 [MAC for ISP's gate] [MAC for WinPC] 0800 74: 66.92.14.160.52685 > 10.0.0.2.25: S 2497864685:2497864685(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp 0 0>

Hmmm, the destination IP was rewritten, but not the source &
destination MAC addr. With the "route-to" rule added, a healthy
converstion begins:

Aug 24 14:30:49.592531 [MAC for FW Internal] [MAC for o.2] 0800 74: 66.92.14.160.52664 > 10.0.0.11.25: S 1218772533:1218772533(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp 0 0>
Aug 24 14:30:49.592698 [MAC for o.2] [MAC for FW Internal] 0800 74: 10.0.0.11.25 > 66.92.14.160.52664: S 3198320541:3198320541(0) ack 1218772534 win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp 1008319780 0> (DF)

Reiterating the questions above- pf knows to divert traffic based on
the redirect rule- can I add any hints to the "rdr" rule so it can
route it at the interface level as well as the tcp address level? Will
it do so automatically under certain circumstances, and if so what are
they?

thanks!

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]