Date: Sat, 30 Jan 2010 06:41:47 +0100 From: =?ISO-8859-1?Q?Kristian_Kr=E6mmer_Nielsen?= <jkkn@jkkn.dk> To: Peter Maxwell <peter@allicient.co.uk> Cc: freebsd-pf@freebsd.org Subject: Re: Possible bug: pf ignores "reply-to" in block-rules Message-ID: <4B63C69B.5080201@jkkn.dk> In-Reply-To: <7731938b1001292131l15a5eef3n7a55f6cd196e10a@mail.gmail.com> References: <4B63B165.2020809@jkkn.dk> <7731938b1001292131l15a5eef3n7a55f6cd196e10a@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Peter, Thanks for the reply. Unfortunately I do not see NAT'ing as an alternative in this case. The main reason for that is that the traffic that I am forwarding is smtp-traffic and I need sendmail to see the actual source IP address to validate the source mail-server and not a NAT-IP. So best case is that the server sees the right public address even it has a different return route. I also considered the multiple routing tables for FreeBSD, which might also help me do this special routing scenario but I found it much more complex than using the nice "pass in reply-to"-feature of pf which works perfect for my allowed traffic. Also I would have to have multiple sendmail-instances running which for each routing scenario - I don't by using pf. The reason for using "block return" is I think it makes debugging much easier than dropping packages. To avoid spoofing I of course have "antispoof"-rules that have higher priority and these are of course set to drop packets and not return them. So again, why is "block return reply-to" not sending the reset-packages back to the specified interface? /Kristian On 30-01-2010 06:31, Peter Maxwell wrote: > Hi Kristian, > > This is quite late, so if my reply doesn't make and sense please > ignore it ;-) Also, I'm not really answering your question, just > suggesting an alternative. > > Instead of using reply-to, can the upstream device that is sending > packets to the gif0 tunnel - or even pf if it works in this scenario - > NAT the source address of incoming packets to a rfc1918 subnet? That > way all you need to do is add an appropriate entry to your routing > table and you don't have to worry about trying to route to overlapping > address space. > > Although I haven't tried it, FreeBSD 8.0 can use multiple routing > tables but have no idea whether this would help. > > I know it comes down to personal taste but can I ask why you are using > "block return" in the first place? There are a few possible > disadvantages: if the packet source address is spoofed your packet > filter will be sending tcp rst/icmp packets back to the wrong IP, and > you are also doubling the resources taken for dealing with what is > essentially spurious traffic. It's not a big deal normally but if > someone attempts some form of denial of service, it won't help either. > > Regards, > > Peter > > > > > > On 30 January 2010 04:11, Kristian Krĉmmer Nielsen<jkkn@jkkn.dk> wrote: > >> Hey, >> >> I am experiencing an issue using reply-to on block rules. >> >> I am a "nice" firewall administrator and always uses "block return" rules, >> thereby pf sends nice reset packets back to clients if they attempt to >> connect to a port that pf is setup to block. >> >> My setup is using a gif0 tunnel to tunnel specific traffic from another >> public IP-address to the server. Since it is important that packages are >> then to be routed back the same way and not using the default-route, I use >> "pass in reply-to gif0"-rules and this worked perfectly for all incoming >> traffic. >> >> But, on my "block return in gif0 reply-to gif0" - pf seem to simply ignore >> the reply-to parameter and instead decides to send the packs back using the >> default route. >> >> I see the packages go out on the wrong interface, in my case my ethernet >> interface (em0), that is the default route for the server. >> >> Could someone check to see if pf respects "reply-to" when sending reset >> packages (block return)? >> >> Or if that is not the case explain to me what "reply-to" is suppose to do on >> "block"-rules? >> >> Best regards, >> Kristian Krĉmmer Nielsen, >> Odense, Denmark >> _______________________________________________ >> freebsd-pf@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-pf >> To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" >> >>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B63C69B.5080201>