pf + ip alias + route-to interrogation
Constant, Benjamin
bconstant at be.tiauto.com
Thu Dec 1 09:24:23 GMT 2005
> -----Original Message-----
> From: Max Laier [mailto:max at love2party.net]
> Sent: mercredi 30 novembre 2005 17:01
> To: Marko Cuk
> Cc: freebsd-pf at freebsd.org; Constant, Benjamin
> Subject: Re: pf + ip alias + route-to interrogation
>
> On Wednesday 30 November 2005 15:59, Marko Cuk wrote:
> > I have same problems with route-to.
> >
> > I have solved the problem with IPF, wich "grabs" packets on output
> > interface and route-to them to proper interface and gateway. The
> > problem is, that it works only when IPF is loaded after booting and
> > boot scripts, because if IPF is loaded at boot time, the
> packet flow
> > obviously changes and IPF won't work.
> > The kldunload ipl / kldload ipl / ipf -f /etc/ipf.rules
> helps, but it
> > is not a proper solution.
> >
> > Max and others... please, help. We can test, try, send some
> data back...
>
> If you want help, please post proper details and complete
> pf.conf Please also describe how it fails. Without complete
> pf.conf it's merely guesswork than proper debugging.
>
> Also: PLEASE DO NOT TOP-POST!
>
> > Constant, Benjamin wrote:
> > >Hello list,
> > >
> > >I've some questions regarding source routing with route-to option.
> > >
> > >Here is what I try to setup:
> > >
> > >I've two network interfaces on a box, one is dedicated to lan, the
> > >other one is dedicated to wan.
> > >On each of these interfaces, there are 1 IP + 1 IP alias
> in another
> > >subnet (security aspect is not important here).
> > >
> > >Here is the scheme:
> > >
> > >10.1.1.0/24 -- 10.1.1.1 192.168.1.2 -- gw1
> [192.168.1.1]
> > > [em0 FreeBSD em1]
> > >10.1.2.0/24 -- 10.1.2.1(alias) 192.168.2.2(alias) -- gw2
> > >[192.168.2.1]
> > >
> > >I'm not performing 'NATting' on this box. All the traffic
> coming from
> > >10.1.1.0/24 is using the kernel routing table of the box
> and going to
> > >gateway 192.168.1.1. I'm doing source routing for every packets
> > >coming from 10.1.2.0/24 and send them to 192.168.1.2.
> > >It using working correctly with the following /etc/pf.conf:
> > >
> > >$ext_if="em1"
> > >$int_if="em0"
> > >
> > >pass out quick on $ext_if route-to ($ext_if 192.168.2.1) from
> > >10.1.2.0/24 to any keep state pass in quick on $int_if route-to
> > >($ext_if 192.168.2.1) from 10.1.2.0/24 to any keep state
> > >
> > ># default rules in case of policy change in future update
> pass in all
> > >flags S/SA keep state pass out all
> > >
> > >I don't understand why I need to use keep state on each rule. If I
> > >remove the keep state keyword, the first packet is using
> the route-to
> > >but the other ones are using the kernel routing table. If
> I remove
> > >the quick keywork, it doesn't work at all (it seems to
> fall in one
> > >of the last two rules depending how the traffic hit the
> box). In an
> > >other mail I can read "unlike filter rules, translation rules are
> > >first-match", what is the policy for route-to? I think it
> should be
> > >the same as for a simple pass or block rule but am I right?
> > >Why do I have to use a "pass in on $int_if..." for all the traffic
> > >coming from the lan? The traffic should hit the rule pass
> out when it
> > >crosses the box.
> > >I can't perform a ping -S lan_ip_alias ip_to_reach, why
> such traffic
> > >isn't using the pass out source routing rule.
> > >This box is running 5.4 stable and the following pf.c
> revision: $FreeBSD:
> > >src/sys/contrib/pf/net/pf.c,v 1.18.2.10 2005/08/06 01:54:11 mlaier
> > >Exp which seem to be the last commit for RELENG_5.
> > >
> > >I'm a bit confused, can someone give me some more
> explanation? Thanks!
>
> Not without seeing your complete ruleset. Quick is a
> two-edged sword and you really need to know what you are
> doing when using it.
>
> --
> /"\ Best regards, | mlaier at freebsd.org
> \ / Max Laier | ICQ #67774661
> X http://pf4freebsd.love2party.net/ | mlaier at EFnet
> / \ ASCII Ribbon Campaign | Against HTML Mail and News
Good morning,
Thanks for your reply, here is my complete pf.conf (some changes has occured
since my last message). There are now 3 network behind the int_if.
The 2 network behind the ext_if haven't changed. Operating system version
and pf revision haven't changed.
The routing table contains an entry for each subnet in <tirange> and each of
these subnet is routed to 192.168.1.2.
How can a the quick keyword interfer with the route-to option? My
understanding of the quick keyword is rule match stop processing, am I
missing something? I was using the attached scheme (not sure it is up to
date) for creating my ruleset. In this scheme, I'm considering everything
between the IN and the KERNEL PROCESSING (routing table?) is specific to
int_if while everything between KERNEL PROCESSING and OUT is related to
ext_if. When I read the scheme and look at the state check, it should not
interfer with the pf-routing but am I right? Is the processing changing
between FreeBSD release? Is there a place where I can find detailed
documentation for the behaviour of pf for each release if it is changing?
Thanks in advance for the time you'll spend on my interrogation!
Regards,
Here is my complete /etc/pf.conf:
The table <tirange> is containing a lot of /24 network subnets, nothing
particular about that.
##### Macros
###################################################################
int_if = "em0"
ext_if = "em1"
table <tirange> persist file "/etc/pf.tirange"
##### Normalization
############################################################
#scrub log-all on $int_if all
#scrub log-all on $int_if all reassemble tcp
#scrub log-all on $ext_if all
#scrub log-all on $ext_if all reassemble tcp
##### Queue Definition
#########################################################
##### Redirection
##############################################################
##### Network Address Translation
##############################################
##### Firewalling and Traffic Shaping
##########################################
# drop broadcast packets
block drop in quick on $int_if from any to $int_if:broadcast
block drop in quick on $ext_if from any to $ext_if:broadcast
# avoid source routing for DDC network ranges for traffic to DEE
pass out quick on $ext_if from 10.1.2.0/24 to 10.1.1.0/24 keep state
pass in quick on $int_if from 10.1.2.0/24 to 10.1.1.0/24 keep state
pass out quick on $ext_if from 10.1.3.0/24 to 10.1.1.0/24 keep state
pass in quick on $int_if from 10.1.3.0/24 to 10.1.1.0/24 keep state
# source routing for DDC network ranges for traffic outside DEE
pass out quick on $ext_if route-to ($ext_if 192.168.2.2) from \
10.1.2.0/24 to <tirange> keep state
pass in quick on $int_if route-to ($ext_if 192.168.2.2) from \
10.1.2.0/24 to <tirange> keep state
pass out quick on $ext_if route-to ($ext_if 192.168.2.2) from \
10.1.2.0/24 to <tirange> keep state
pass in quick on $int_if route-to ($ext_if 192.168.2.2) from \
10.1.3.0/24 to <tirange> keep state
# source routing for DDC
pass out quick on $ext_if route-to ($ext_if 192.168.2.2) from \
192.168.159.0/24 to <tirange> keep state
# overwritten default policy (in case of changes when updating)
pass in all flags S/SA keep state
pass out all
The information contained in this transmission may contain privileged and
confidential information. It is intended only for the use of the
person(s) named above. If you are not the intended recipient, you are
hereby notified that any review, dissemination, distribution or
duplication of this communication is strictly prohibited. If you are not
the intended recipient, please contact the sender by reply email and
destroy all copies of the original message. This communication is from TI
Automotive.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: packet_flow.png
Type: application/octet-stream
Size: 55670 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-pf/attachments/20051201/1b4bb766/packet_flow-0001.obj
More information about the freebsd-pf
mailing list