pf + ip alias + route-to interrogation

[Max Laier]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-pf/attachments/20051130/e445ad3a/attachment.bin