Darren Reed
2007-01-13 15:41:43 UTC
Hi,
So i've been implementing some new features in ipfilter, whether
or not they make it a 5.0, I'm not sure...maybe a few people can
let me know what they think about that..
So what are these new features?
There are 3 new commands for ipnat.conf:
rewrite - change both source and address fields for incoming or
outgoing packets
encap - encapsulated the packet in a new IP header (this will be
compatible, I hope, with IPENCAP tunnels elsewhere0
divert - encapsulate the packet into an IP+UDP packet
To help people use these, I've rewritten the ipnat.conf man page.
divert
------
A divert rule looks like this:
divert in on le0 proto udp from any to any port = 53 ->
src 127.0.0.1,54 dst 127.0.0.1,5300;
note the ";" on the end of the line. to the left of the "->" is
the original packet to be matched, on the right, the IP/UDP header
to create and put in front of the packet. Reply packets from that
socket will have the IP+UDP headers removed when they get back to
IPFilter. I'm hoping this will provide cross-platform "divert"
functionality but it needs more widespread testing than what I've
been able to achieve.
encap is pretty much the same as divert, minus the port numbers to
the right of "->".
rewrite
-------
Rewrites have a subset of the combined functionality of rdr/map rules.
As an example of how the man page has been rewritten, I've included the
contents of it for this new command below.
ipmon
=====
You can now use ipmon.conf to as the place to specify how log records
are sent to syslog (facility & priority) rather than needing to do it
in filter rules.
ipf
===
As part of the "keep state" options, you can now specify a rule group
to which ICMP replies can be filtered by - "... keep state(icmp-head
icmprules)"
It is also now possible to position stateful filtering checks, inbound
and outbound nat lookups. If this is done, the traditional checks are
no longer performed. This is done as follows:
call now fr_checkstate in on le0 from any to any
call now fr_ipfnatin in on ppp0 all
call now fr_ipfnatout out on bge0 from bge0/32 to any
Oh, being 5.0.0, it is a development version, there's nothing release
quality about it (well, you might argue that for others too .. >:->),
this is just to get some feedback from people on features and enable
some people to try/test a few things out beyond my limited scope.
Perhaps most importantly, most of my work to date has been limited to
using NetBSD.
Cheers,
Darren
http;//coombs.anu.edu.au/~avalon/ip_fil5.0.0.tar.gz
MD5 (/home/darrenr/ip_fil5.0.0.tar.gz) = 7798797c1929cb55c182d3088f40b0b5
REWRITING SOURCE AND DESTINATION
Whilst the above two commands provide a lot of flexibility in
changing
addressing fields in packets, often it can be of benefit to
translate
both source and destination at the same time or to change the
source
address on input or the destination address on output. Doing
all of
these things can be accomplished using rewrite NAT rules.
A rewrite rule requires the same level of packet matching as
before,
protocol and source/destination information but in addition
allows
either in or out to be specified like this:
rewrite in on ppp0 proto tcp from any to any port = 80 ->
src 0/0 dst 127.0.0.1,3128;
rewrite out on ppp0 from any to any ->
src 0/32 dst 10.1.1.0/24;
On the RHS we can specify both new source and destination
information
to place into the packet being sent out. As with other rules
used in
ipnat.conf, there are shortcuts syntaxes available to use the
original
address information (0/0) and the address associated with the
network
interface (0/32.) For TCP and UDP, both address and port
information
can be changed. At present it is only possible to specify
either a
range of port numbers to be used (X-Y) or a single port number (=
X) as
follows:
rewrite in on le0 proto tcp from any to any port = 80 ->
src 0/0,2000-20000 dst 127.0.0.1,port = 3128;
There are four fields that are stepped through in enumerating
the num-
ber space available for creating a new destination:
source address
source port
destination address
destination port
If one of these happens to be a static then it will be skipped
and the
next one incremented. As an example:
rewrite out on le0 proto tcp from any to any port = 80 ->
src 1.0.0.0/8,5000-5999 dst 2.0.0.0/24,6000-6999;
The translated packets would be:
1st src=1.0.0.1,5000 dst=2.0.0.1,6000
2nd src=1.0.0.2,5000 dst=2.0.0.1,6000
3rd src=1.0.0.2,5001 dst=2.0.0.1,6000
4th src=1.0.0.2,5001 dst=2.0.0.2,6000
5th src=1.0.0.2,5001 dst=2.0.0.2,6001
6th src=1.0.0.3,5001 dst=2.0.0.2,6001
and so on.
As with map rules, it is possible to specify a range of
addresses by
including the word range before the addresses:
rewrite from any to any port = 80 ->
src 1.1.2.3 - 1.1.2.6 dst 2.2.3.4 - 2.2.3.6;
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
So i've been implementing some new features in ipfilter, whether
or not they make it a 5.0, I'm not sure...maybe a few people can
let me know what they think about that..
So what are these new features?
There are 3 new commands for ipnat.conf:
rewrite - change both source and address fields for incoming or
outgoing packets
encap - encapsulated the packet in a new IP header (this will be
compatible, I hope, with IPENCAP tunnels elsewhere0
divert - encapsulate the packet into an IP+UDP packet
To help people use these, I've rewritten the ipnat.conf man page.
divert
------
A divert rule looks like this:
divert in on le0 proto udp from any to any port = 53 ->
src 127.0.0.1,54 dst 127.0.0.1,5300;
note the ";" on the end of the line. to the left of the "->" is
the original packet to be matched, on the right, the IP/UDP header
to create and put in front of the packet. Reply packets from that
socket will have the IP+UDP headers removed when they get back to
IPFilter. I'm hoping this will provide cross-platform "divert"
functionality but it needs more widespread testing than what I've
been able to achieve.
encap is pretty much the same as divert, minus the port numbers to
the right of "->".
rewrite
-------
Rewrites have a subset of the combined functionality of rdr/map rules.
As an example of how the man page has been rewritten, I've included the
contents of it for this new command below.
ipmon
=====
You can now use ipmon.conf to as the place to specify how log records
are sent to syslog (facility & priority) rather than needing to do it
in filter rules.
ipf
===
As part of the "keep state" options, you can now specify a rule group
to which ICMP replies can be filtered by - "... keep state(icmp-head
icmprules)"
It is also now possible to position stateful filtering checks, inbound
and outbound nat lookups. If this is done, the traditional checks are
no longer performed. This is done as follows:
call now fr_checkstate in on le0 from any to any
call now fr_ipfnatin in on ppp0 all
call now fr_ipfnatout out on bge0 from bge0/32 to any
Oh, being 5.0.0, it is a development version, there's nothing release
quality about it (well, you might argue that for others too .. >:->),
this is just to get some feedback from people on features and enable
some people to try/test a few things out beyond my limited scope.
Perhaps most importantly, most of my work to date has been limited to
using NetBSD.
Cheers,
Darren
http;//coombs.anu.edu.au/~avalon/ip_fil5.0.0.tar.gz
MD5 (/home/darrenr/ip_fil5.0.0.tar.gz) = 7798797c1929cb55c182d3088f40b0b5
REWRITING SOURCE AND DESTINATION
Whilst the above two commands provide a lot of flexibility in
changing
addressing fields in packets, often it can be of benefit to
translate
both source and destination at the same time or to change the
source
address on input or the destination address on output. Doing
all of
these things can be accomplished using rewrite NAT rules.
A rewrite rule requires the same level of packet matching as
before,
protocol and source/destination information but in addition
allows
either in or out to be specified like this:
rewrite in on ppp0 proto tcp from any to any port = 80 ->
src 0/0 dst 127.0.0.1,3128;
rewrite out on ppp0 from any to any ->
src 0/32 dst 10.1.1.0/24;
On the RHS we can specify both new source and destination
information
to place into the packet being sent out. As with other rules
used in
ipnat.conf, there are shortcuts syntaxes available to use the
original
address information (0/0) and the address associated with the
network
interface (0/32.) For TCP and UDP, both address and port
information
can be changed. At present it is only possible to specify
either a
range of port numbers to be used (X-Y) or a single port number (=
X) as
follows:
rewrite in on le0 proto tcp from any to any port = 80 ->
src 0/0,2000-20000 dst 127.0.0.1,port = 3128;
There are four fields that are stepped through in enumerating
the num-
ber space available for creating a new destination:
source address
source port
destination address
destination port
If one of these happens to be a static then it will be skipped
and the
next one incremented. As an example:
rewrite out on le0 proto tcp from any to any port = 80 ->
src 1.0.0.0/8,5000-5999 dst 2.0.0.0/24,6000-6999;
The translated packets would be:
1st src=1.0.0.1,5000 dst=2.0.0.1,6000
2nd src=1.0.0.2,5000 dst=2.0.0.1,6000
3rd src=1.0.0.2,5001 dst=2.0.0.1,6000
4th src=1.0.0.2,5001 dst=2.0.0.2,6000
5th src=1.0.0.2,5001 dst=2.0.0.2,6001
6th src=1.0.0.3,5001 dst=2.0.0.2,6001
and so on.
As with map rules, it is possible to specify a range of
addresses by
including the word range before the addresses:
rewrite from any to any port = 80 ->
src 1.1.2.3 - 1.1.2.6 dst 2.2.3.4 - 2.2.3.6;
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de