OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Adrian Buxton (Adrian.Buxtonteam.ozemail.com.au)
Date: Fri Jun 21 2002 - 01:24:00 CDT

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

    Hi all,

    Recently, I decided it was time to build another openbsd firewall. All
    previous firewall gateways I built were running NAT and everything had
    generally worked quite well using my firewall rules, which usually look
    like:

    nat.conf
    --------
    ext_if="tun0"
    int_if="ne3"
    int_nets="{ 192.168.15.0/24 }"

    nat on $ext_if from $int_nets to any -> $ext_if

    pf.conf (with junk removed)
    -------
    ext_if="tun0"
    int_if="ne3"
    spoofed="{ 10.0.0.0/8, 172.16.0.0/16, 192.168.0.0/16, 127.0.0.0/8 }"
    int_nets="{ 192.168.15.0/24 }"

    # block and log spoofed traffic on external interface #
    block in log quick on $ext_if from $spoofed to any

    # loopback adapter can go anywhere #
    pass in quick on lo0 from any to any
    pass out quick on lo0 from any to any

    # firewall machine can go anywhere
    pass out quick on $ext_if proto tcp from $ext_if to any flags S keep state
    pass out quick on $ext_if proto { icmp, udp } from $ext_if to any keep state
    pass out quick on $int_if proto tcp from $int_if to any flags S keep state
    pass out quick on $int_if proto { icmp, udp } from $int_if to any keep state

    # access from local networks #
    pass in quick on $int_if proto tcp from $int_nets to any flags S keep state
    pass in quick on $int_if proto { icmp, udp } from $int_nets to any keep
    state

    # block anything not matching
    block in log quick from any to any
    block out log quick from any to any

    As stated this works quite well for OpenBSD gateways running in a NAT
    configuration. However, if you adopt the same rule configuration philosophy
    on a non-nat gateway the return traffic gets blocked.

    More specifically, I have noticed that traffic flows in the internal
    interface, out the external interface, and the return traffic from the
    destination host is blocked attempting to enter the external interface. I'm
    guessing this is because state info is kept on a specific interface only, so
    by filtering inbound on the internal interface the state information is
    non-existent on the external interface and the return traffic is
    consequently dropped.

    Why then does this work correctly when running in NAT mode?? Does anyone
    know if Ipfilter exhibited similar behaviour?

    I do prefer the idea of filtering at the ingress point rather than the
    egress, but I see no way of doing this except to create two 'keep state'
    rules for each traffic session. This method create a state table twice the
    size of one which used egress filtering only?

    I was actually working towards the implementation of a transparent bridging
    firewall. Through my research I have read that unlike routed firewalls, in
    bridging mode packets traverse the bridge twice, in one interface and out
    the other. The tests I have performed suggest that the traffic passes
    through both interfaces twice regardless of whether running in routing or
    bridging mode. In $int_if, out $ext_if, then in $ext_if and out $int_if -
    the same in both cases (assuming of course traffic is travelling from int to
    ext). If this is simply a misunderstanding on my part I would appreciate it
    if someone would clarify exactly how this works.

    One final point is that the (un?)official PF howto document gives an example
    of a ruleset under '2.10 Putting it all together'
    My ruleset is essentially the same, keeping state on an internal interface
    and expecting the return traffic to pass through the external interface on
    the way through. Neither work on my system... hope someone knows why!

    Thanks for reading.

    Regards,
    Adrian.