Date: Thu, 1 Dec 2005 10:24:11 +0100 From: "Constant, Benjamin" <bconstant@be.tiauto.com> To: freebsd-pf@freebsd.org Subject: RE: pf + ip alias + route-to interrogation Message-ID: <B6D948D84090A54ABCD88AA391DAAC8C021F7D42@tiasbel00ex00.be.eu.tiauto.com>
index | next in thread | raw e-mail
[-- Attachment #1 --] > -----Original Message----- > From: Max Laier [mailto:max@love2party.net] > Sent: mercredi 30 novembre 2005 17:01 > To: Marko Cuk > Cc: freebsd-pf@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@freebsd.org > \ / Max Laier | ICQ #67774661 > X http://pf4freebsd.love2party.net/ | mlaier@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. [-- Attachment #2 --] PNG IHDR = w $g gAMA 7 IDATxy\0g YA)(bQQXKV[zim.Z,WZ\ XAEH 2ӛ"@2|#33'<99sf IB0uBq`"D?fDciiYXXhchvȐ! CQ(dP(oAxoIDJJ+;EFdv-eǎW\ٻw+ҾRRRM6GәR̴qtdaaa``oj ñ`22s w͛7bduuu#F9sfhh(`x<;;;>Oik̙Y- :///_b~@ p8T:::r8V93ovqN)))ϟQAZdjjM]Gd̽N3fÆ }X,>,,,V(b?5[ 2d͛gΜYWWg꺴U]]]xxܹsAKM`X5-s$~ g\.֖ [J{$w>|8 vrrD{;ֈ;PiEKx<IfXmk֬1<^FSVV O>7F,k/իWZRKX,xl6ʊbwMB;'eee?K>dB4~~~CcaɫW1zqqq /d0Tr|>E-G<;sXLkѱL]Vqg}kvÆ "#_{~͚5F) ZNiDwʔ)Ѷ̻hߧd_6m@ rvvv<{$)-LB2279uZRm2NBF35xuނ$֢I@bZ:L'io)Mt1ES0ŴuNނ]LkQlߤOt1ELt1Es6bZLs!.T:W]Lk u~.Ȅ:ykN.ȴ:y{bZLbZAoo)Jt1E栫4FIt1EfDZd>З-.ȬtbXi-2+]}0 Ŵ.B+]Lk߶'"[JK]Lky K]Lk-4bZYڽ(ѥyaZSno)M]LkDZdh L]Ot0EۿM<Yӭ]V.SK0E yyyX,1ۿl6moo?h 6x<ͶbX B9\\\ @"`Zs06]__|>1u1aaaa }!$ks`Ά`"D?-Bq`"D?-Bq`"D?8߿ yyy ...AAA&B/q˖-cԭ?5Mbb}j@.BR_la~ $$ O BBB0h9ø Xt)ϧ.]j <' $) +++G!3- Ab"3_<<<
