Couple of network questions (NAT, firewalls) - BSD

This is a discussion on Couple of network questions (NAT, firewalls) - BSD ; Hello, I'm a recent FreeBSD 7 user and I want to do in FreeBSD things I've done on Linux Let's start with firewalls. I've compiled my kernel to support both ipfw and ipf. The first surprise was loosing all networks ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Couple of network questions (NAT, firewalls)

  1. Couple of network questions (NAT, firewalls)

    Hello,
    I'm a recent FreeBSD 7 user and I want to do in FreeBSD things I've
    done on Linux
    Let's start with firewalls.
    I've compiled my kernel to support both ipfw and ipf. The first
    surprise was loosing all networks upon reboot, but I understood that
    this is default policy of these firewalls. I solved that for ipfw with
    following FIREWALL_SCRIPT
    ipfw add 65000 allow ip from any to any

    I still can't understand how to disable ipf (I don't want it
    currently) and I have to type after every reboot:
    ipf -D

    I tried with ipfilter_enable="NO" in rc.conf but this is not the way.

    Issue number 2 - NAT. I succeeded running natd and a simple divert
    rule for ipfw did the job:
    ipfw add 500 divert natd all from any to any via re0

    However I want only one machine to have access to this. I tried these:
    ipfw add 500 divert natd all from 192.168.0.5 to any via re0 pfw add
    500 divert natd all from any to 192.168.0.5 via re0

    (Ofcourse after flushing rules)
    OK that is interesting. I was logged in from 192.168.0.5 and after I
    changed the divert rule I lost connection from 192.168.0.5 to the
    server (which is 1 meter away and doesn't have any other rules in the
    firewall list exept pass all). Why is that happening? I'm sshing
    directly to the internal address - 192.168.0.1 which is an alias of
    re0, which doesn't care of what NAT state is. It should be pingable
    even if no NAT is established. Right?

    The second thing I tried is to pass some options to the natd daemon
    (like -redirect_address). For the purpose of that I first killed the
    natd daemon, and guess what - the secondary machine got cutoff again.
    So what is that connection between nat and ssh? I'm doing a simple
    peer to peer connection and there is nothing wrong with the IP
    settings.
    Am I going into the right way with -redirect_address? I didn't manage
    to try this out after the connection was cut.
    And how can I redirect a public address if my ISP have provided
    several? Is it with that -redirect_address option?

  2. Re: Couple of network questions (NAT, firewalls)

    On Fri, 11 Jul 2008 07:07:47 -0700 (PDT),
    ivanatora wrote:
    > I've compiled my kernel to support both ipfw and ipf.


    If you're just fooling around, then you might want to *not* do that
    and instead load the appropriate modules on demand.


    > The first surprise was loosing all networks upon reboot,


    That is pretty well documented, actually, and makes sense from a
    security PoV. If you don't want that you either make the packet filters
    default to allow or you provide a suitable ruleset through the usual
    startup mechanism(s).


    > Issue number 2 - NAT.


    I'm not quite sure what you're trying to do, or what you're trying to
    ask. But do consider that any connection through NAT causes a NAT-state
    entry in the internal nAT-state table, and if you change the rules out
    from under it, the dynamic state falls out and all connections affected
    need to be re-established.


    --
    j p d (at) d s b (dot) t u d e l f t (dot) n l .
    This message was originally posted on Usenet in plain text.
    Any other representation, additions, or changes do not have my
    consent and may be a violation of international copyright law.

  3. Re: Couple of network questions (NAT, firewalls)

    I've discovered some simple facts - that rule:
    ipfw add 500 divert natd all from any to any via re0
    Just redirects traffic to port 8668 (natd) and from there the natd
    daemon handles these packets. So if I try to make a connection from
    the server box to the secondary box (or vice versa), that connection
    will be diverted trough the natd daemon. If the daemon is killed, the
    connection will be diverted into the null After stoping the daemon
    (and removing the divert rule) I managed to establish another clean
    connection, and you are right that it bypasses the nat state table.
    Okay, let's say I'm clear with that, even if I can't explain it in
    plain english

    The other question - how can I restrict the clients using that server
    as a NAT gateway? If I have that box 192.168.0.5 and another
    completely random box 192.168.0.6, how can I restrict only 192.168.0.5
    to be allowed to connect to the gateway? I don't mean completely
    cutting out the other box, but just disallowing it to use nat.

    Oh and how can I build a kernel feature as a module? If I drop that
    "options IPFIREWALL" will ipfw will be build as a module
    *automatically*?

    Regards, Ivan.

    On Jul 11, 5:22 pm, jpd wrote:
    > On Fri, 11 Jul 2008 07:07:47 -0700 (PDT),
    >
    > ivanatora wrote:
    > > I've compiled my kernel to support both ipfw and ipf.

    >
    > If you're just fooling around, then you might want to *not* do that
    > and instead load the appropriate modules on demand.
    >
    > > The first surprise was loosing all networks upon reboot,

    >
    > That is pretty well documented, actually, and makes sense from a
    > security PoV. If you don't want that you either make the packet filters
    > default to allow or you provide a suitable ruleset through the usual
    > startup mechanism(s).
    >
    > > Issue number 2 - NAT.

    >
    > I'm not quite sure what you're trying to do, or what you're trying to
    > ask. But do consider that any connection through NAT causes a NAT-state
    > entry in the internal nAT-state table, and if you change the rules out
    > from under it, the dynamic state falls out and all connections affected
    > need to be re-established.
    >
    > --
    > j p d (at) d s b (dot) t u d e l f t (dot) n l .
    > This message was originally posted on Usenet in plain text.
    > Any other representation, additions, or changes do not have my
    > consent and may be a violation of international copyright law.



+ Reply to Thread