On Mon, 16 Aug 2004, Herron, David S wrote:

> I'm just starting to research the rule output so I can better read
> this... can any of you tell me if you see anything out of place that
> would cause a PPTP session to fail from a client on the LAN side to a
> server on the WAN side, with no NATing enabled?  I did change some IP's
> to fall in line with my previous network description.
> 
> Here is the output of ipfstat -hnio:
[...]
> 14877 @16 block in log quick on xl0 from any to any head 100
> 1707 @1 pass in quick from 10.0.3.0/24 to 10.0.3.1/32 keep state group 100
> 13170 @2 pass in quick from any to any keep state keep frags group 100
> 4700 @17 block in log quick on xl1 from any to any head 200
> 4700 @1 pass in quick from any to any keep state keep frags group 200
> 0 @18 block in log quick from any to any

I didn't see anything obviously wrong assuming "pass everything" is what
you want (at least for testing).  But you can't tell much from the hit
counters with general rules.  Adding explicit pass rules for GRE (ahead of
the general ones) would give GRE its own counters.  Note that the normal
successful case should only count once in the rule, since it will create a
state entry that passes further packets of that session before getting to
the rules.  The state entry will time out after a while.

If you add a GRE pass rule in each direction, you should see those show up
in the "group 100" and "group 200" sections.  Looking at the counters
before and after the attempt should show whether GRE packets are passing
in either direction, and looking at the state entry (if it works) will
show how many packets passed after the first.

You could also add an explict pass rule for TCP port 1723 just to check
the control connection, although it sounds like that part is
working.  Even if you don't add the rule, you should see its state entry.

					Fred Wright