[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipfilter
Subject:    nat rdr/mapping questions..
From:       ipf Adrian Buxton <ipfilter () internal ! ozemail ! com ! au>
Date:       2000-08-31 2:17:00
[Download RAW message or body]

Good morning everyone,

I've just implemented an IPfilter + NAT system as a replacement of a
firewall/1 system. I've been using ipf in other areas for awhile but have a
question regarding this setup//

The network scenario is as follows:

      --------------|---------|------------|
      |         de0 |ipfilter |de1         |
      |             |         |            |
--------------      |---------|       -------------
192.168.1.0/24                        203.108.1.0/24


de0 = 192.168.1.1
de1 = 203.108.1.14

I have the following in my /etc/ipnat.rules file:

map de1 192.168.1.0/24 -> 203.108.1.14/32 proxy port ftp ftp/tcp
map de1 192.168.1.0/24 -> 0/32


I also have some systems on the outside (203.108.1.0 net) that require
access to machines on the 192.168.1.0 net. Unfortunately whenever a machine
outside tries to initiate this connection, the firewall responds on behalf
of the dest host, because of this rule I presume:

map de1 192.168.1.0/24 -> 0/32

The host that initiated the connection then sends a reset packet to the
firewall and the cycle goes on. I managed to get around it by changing
/etc/ipnat.rules to the following:

rdr de1 192.168.1.15/32 port 0 -> 192.168.1.15 port 0
map de1 192.168.1.0/24 -> 203.108.1.14/32 proxy port ftp ftp/tcp
map de1 192.168.1.0/24 -> 0/32

So, any packets destined to the 1.15 host are not tampered with by the map
rule?

Anycase, I would have assumed that the map rule would have only operated on
the packet if it was sourced from 192.168.1.0/24 rather than if was either
sourced or destined to.. is there a reason for this behaviour?

Are there any plans to specify src or dst in the map rule.. like for
example:

map de1 src 192.168.1.0/24 -> de1/32

This modify packets from 192.168.1.0/24 only.. not destined to that net.

Anycase, are there any other ways to achieve the same thing (bypass map
rule), without using a RDR rule? One problem I can see is trying to send
other ip protocols besides tcp & udp to the internal host, the rdr rule
won't handle this. Eg, ipsec, etc.. anycase, look forward to your thoughts.


Thanks

Adrian

[prev in list] [next in list] [prev in thread] [next in thread]