Quantcast

ICMP Ruleset Behavior

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

ICMP Ruleset Behavior

Aaron Hofer
Greetings,

Trying to replicate some functionality with PF that I had with a cisco asa.  I'm trying to explicitly allow echo requests outbound and only echo replies inbound but it's not working.  Here's my current rules for this, but I can't ping anything beyond the external interface though.

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?  

Thanks
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ICMP Ruleset Behavior

Peter N. M. Hansteen-3


On 07/30/16 06:08, Aaron Hofer wrote:
> Trying to replicate some functionality with PF that I had with a cisco
> asa.  I'm trying to explicitly allow echo requests outbound and only
> echo replies inbound but it's not working.  Here's my current rules for
> this, but I can't ping anything beyond the external interface though.
>
> 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

Last match wins, so if you move the block up before the pass rules, you
should see a difference.


--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ICMP Ruleset Behavior

Tony Martino
In reply to this post by Aaron Hofer
Hi Aaron,

Removing the no state allows PF to assign a state to an outgoing ICMP echo
request. The state means that PF will allow echo replies from the IP the
request was directed to in with no additional pass rule required.

This stateful configuration is the best way to acheive the result you
desire. The ASA, a sateful firewall, works the same way.

-Tony

On Fri, 29 Jul 2016, Aaron Hofer wrote:

> Greetings,
>
> Trying to replicate some functionality with PF that I had with a cisco asa. 
> I'm trying to explicitly allow echo requests outbound and only echo replies
> inbound but it's not working.  Here's my current rules for this, but I can't
> ping anything beyond the external interface though.
>
> 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?  
>
> Thanks
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ICMP Ruleset Behavior

Kenneth Gober
In reply to this post by Aaron Hofer
On Sat, Jul 30, 2016 at 12:08 AM, Aaron Hofer <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ICMP Ruleset Behavior

Aaron Hofer
Excellent, Thank you, Tony, Ken!

On Sat, Jul 30, 2016 at 10:45 AM, Kenneth Gober <[hidden email]> wrote:
On Sat, Jul 30, 2016 at 12:08 AM, Aaron Hofer <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ICMP Ruleset Behavior

Stuart Henderson
In reply to this post by Aaron Hofer
The firewall state allows ICMP responses that match an existing state. For example, echo replies that match a permitted echo request, ICMP responses to outgoing TCP connections, etc.

On 30 July 2016 05:08:29 BST, Aaron Hofer <[hidden email]> wrote:

>Greetings,
>
>Trying to replicate some functionality with PF that I had with a cisco
>asa.  I'm trying to explicitly allow echo requests outbound and only
>echo
>replies inbound but it's not working.  Here's my current rules for
>this,
>but I can't ping anything beyond the external interface though.
>
>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?
>
>Thanks

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ICMP Ruleset Behavior

Panagiotis Galiotos
In reply to this post by Peter N. M. Hansteen-3
Dear Peter,

indeed last match wins, but both the other rules have the quick keyword.
So if there was a match, it should happen.
So in this case, why does this order match ?

Panagiotis Galiotos

On Sat, Jul 30, 2016 at 2:30 PM, Peter N. M. Hansteen <[hidden email]> wrote:


On 07/30/16 06:08, Aaron Hofer wrote:
> Trying to replicate some functionality with PF that I had with a cisco
> asa.  I'm trying to explicitly allow echo requests outbound and only
> echo replies inbound but it's not working.  Here's my current rules for
> this, but I can't ping anything beyond the external interface though.
>
> 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

Last match wins, so if you move the block up before the pass rules, you
should see a difference.


--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Loading...