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
