Possible bug: pf ignores "reply-to" in block-rules

[Kristian Kræmmer Nielsen]

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 at 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 at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-pf
>> To unsubscribe, send any mail to "freebsd-pf-unsubscribe at freebsd.org"
>>
>>