ICMP block



  • Hello everyone,

    I am new to the forum and used PfSense a few times in the pas ( I LOVE IT :D )
    The reason why I signed up is because I need your help…

    Here is the case;
    1 NIC in subnet 192.168.100.0
    1 NIC in subnet 192.168.200.0

    I block ICMP from 192.168.200.0  to 192.168.100.0<-- this rule works ( when the rule is disabled, the ping does come through and when enabled it fails, so this is ok )
    I am able to ping the other way because I enabled any to any on the 192.168.100.0 to 192.168.200.0 ( test purposes of course ).

    Scenario;
    When I start an infinite ping from 192.168.200.10(host) to 192.168.100.2(host) the ping failes but I keep it running.
    When I start a ping on the other end ( from 192.168.100.2 to 192.168.200.10 ) while the above ping is runing, this pings succeeds ( as expected because of the any to any allow rule )..
    So far all normal right...
    However, the first ping is also starting to receive echo replies..........
    This is porbably because of the keep states of the firewall but I would expect it to inspect the ping packets so that the 192.168.200.10 is only able to send icmp echo replies instead of requests.

    Question;
    Is my statement correct that PfSense doesn't do a packet inspection but just allows all ICMP states?
    If I am right, why not?
    If I am wrong, why am I wrong?

    Thanks all :D



  • I just tried creating multiple pings in different windows going out to a common destination. The states were ambiguous. There is a good chance that because ICMP has no ports, there is no simple way to tell the difference between pings going out vs in. The firewall could DPI and look to see if their echo requests vs responses, but that would increase overhead and be an exception to the general rule.

    Someone else may have a better or more correct answer.



  • Hi Harvy,

    Thanks for you reply.
    Your answer is partly correct but still isn't answering my question fully.

    However, ICMP only uses Layer 3 of the OSI and no layer 4.
    For this reason I can confirm that it will not look at any ports.
    ICMP is in an IP packet, the ICMP packet is made up out of 3 segments (TYPE, CODE, CHECKSUM ).
    So if DPI is an option ( which again, I am not sure if it is or isn't thats why I am posting my question ), then you could DPI the type and make sure only type 0 is allowed ( reply ) instead of also allowing 8 ( echo request ) back into the other direction.

    It uses types in the packets, so I find that PfSense should at least have an option to do deep state packet filtering.
    Example, if I sniff the network or know that there is a PfSense I can do a so called network ping and just wait for an engineer to do a ping to some hosts on the network.
    Worst case scenario is that a malicious user knows that there is an host on a protected network but you still only have ICMP.
    As this doesn't sound bad, I don't agree that this is an acceptable loss in a firewall.
    DPI should at least be implemented.

    Thanks again for your reply, I like to discuss in dept.

    If someone could tell me if;

    • PfSense doesn't check the type of ICMP?
    • If it is possible to enable DPI in ICMP?
    • If I am correct with my theory that is is not doing packet inspections tell my why not
    • If I am wrong with my theory, tell me why I am wrong.

    Thanks in advance.

    Regards,

    Andre



  • DPI (layer-7) has nothing to do with ICMP, since ICMP is a layer-4 proto.

    pfSense has some hidden firewall rules. You might see if those are causing some unexpected problems. You can view them with pftop.



  • Hi,

    Thanks for the reply.

    To start with; DPI, since when is this only layer 7?
    Second; ICMP, since when is this layer 4?
    Third reply; how does pointing to pftop answer my question?

    Thanks

    Regards



  • @dre2007:

    To start with; DPI, since when is this only layer 7?
    Second; ICMP, since when is this layer 4?
    Third reply; how does pointing to pftop answer my question?

    How would DPI help you? There is no need for "deep inspection" of ICMP packets since pf is already fully aware of the packet. Technically, the ICMP header is at layer-4, but it seems to be commonly referred to as a layer-3 proto. Regardless, DPI is unneeded because pf is aware of layer 3 & 4.

    If pf is confusing ICMP's states, that's a bug.

    Use pftop to look at all of your firewall rules.



  • Hi,

    Thanks for the reply.
    How would DPI help me?, because  it needs to investigate the ICMP type.
    Deep inspection is a term, it needs to inspect, in this example, the ICMP type.

    I do am curiouse of why ICMP is layer 4, could you please explain me?, as far as I am aware, ICMP is not about delivering packets to the end destination but just to find out the destination.

    I Know pf is aware of layer 3 and 4.

    However, since you keep refering to pftop, I will investigate it.

    Thanks again for your reply.

    Regards



  • @dre2007:

    How would DPI help me?, because  it needs to investigate the ICMP type.
    Deep inspection is a term, it needs to inspect, in this example, the ICMP type.

    I do am curiouse of why ICMP is layer 4, could you please explain me?, as far as I am aware, ICMP is not about delivering packets to the end destination but just to find out the destination.

    I Know pf is aware of layer 3 and 4.

    However, since you keep refering to pftop, I will investigate it.

    ICMP is encapsulated within an IP packet (layer-3), so it has a source & destination IP, just like all IP packets.

    pf is aware of ICMP's headers, which you could call "inspection". There is no deeper level of inspection possible.

    Show your firewall rules.