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