Excellent, Thank you, Tony, Ken! On Sat, Jul 30, 2016 at 10:45 AM, Kenneth Gober <[email protected]> wrote:
> On Sat, Jul 30, 2016 at 12:08 AM, Aaron Hofer <[email protected]> > wrote: > > > > pass out quick on egress inet proto icmp icmp-type echoreq no state > > pass in quick on egress inet proto icmp icmp-type echorep no state > > block quick on egress inet proto icmp all > > > > If I remove the 'no state' part, I can ping, but I don't need the second > > line which I don't really understand why I don't. So I guess my > questions > > are, why does the above ruleset not work, and why does it work if I > remove > > 'no state' or use default of keep state but comment out the second rule? > > Shouldn't the echoreply packets be getting blocked on the way back in? > > > > What am I missing? Do i need to do something with NAT's? > > It's not obvious to my why your ruleset isn't working as-is, but the reason > it works if you remove the "no state" is because state is used not only for > additional outbound packets, but also all the inbound reply packets. > > This allows you to remove the second line and tighten up your security. > Instead of allowing any ICMP echo reply in (even unsolicited/forged > replies) > keeping state will allow only the specific replies that match > previously-passed > echo requests. > > Regarding NAT, ICMP traffic is no different from any other kind of IP > traffic. > If you need to use NAT for other things, you need it for ICMP also. If > your > network configuration doesn't require NAT, then ICMP won't need it either. > > Note that NAT generally applies only to forwarded traffic. Traffic > that originates > from your PF host won't typically need it. > > Whether you need NAT or not depends on the type of service you have > from your ISP (or whoever is providing your egress network connection). > You didn't say what it is, so I can't say whether you need it or not. > > -ken >
