(IPF) Allowing ICMP from a specific IP address

ShelLuser

ShelLuser

Hi gang,

Are there any known issues when it comes to IPF keeping the state of ICMP traffic? The reason I'm asking is because I'm having some odd problems where only 1 ICMP packet finds its way back to other.server.

Here is the firewall script I'm using:

Code: 
## Incoming traffic ##

# local loopback
pass in quick on lo0

# Temporary whitelist
pass in quick proto icmp from remote.server

## Log & block
#log in quick all
block in quick all

## Outgoing

pass out quick on lo0 all
pass out quick on vtnet0 all keep state
Probably needless to say, but remote.server resembles an IP address, and I'm 100% that this IP address is correct.

The moment I try to ping this server from remote.server only 1 ICMP packet in the sequence finds its way back:

Code: 
[peter@smtp ~]$ ping server
PING server (xxx.xxx.xxx.xxx) 56(84) bytes of data.
64 bytes from server (xxx.xxx.xxx.xxx): icmp_seq=1 ttl=59 time=1.25 ms
(* the names and addresses have been changed to protect the innocent, namely me ;) )

Usually only 1 packet finds its way back, sometimes even 2. But that's it.

I'm pretty confused right now, I hope one of you guys has an idea.
 
Thanks guys!

Rest assured: I checked the handbook first and according to that page (section 31.5.12 called "Stateful filtering") it should also allow ICMP packets.

But when re-reading this it directly mentions: "IPF stateful filtering will also allow ICMP packets related to an existing TCP or UDP session.". If you start pinging a server I doubt you'll be sending related TCP or UDP packets.

Anyway, the more I read about ipf the more I have to admit that it seems dated. I'm going to look into pf(4) today and see what I can find.
 
Solved, I'll change the status in a moment. I'll also won't be diving deeper into pf (even though briefly reading the PF section in the handbook has given me this idea).

Because I only allow specific data to enter my firewall (incoming rules) the last outgoing rule is one which says to "keep state" so that return traffic can find it's way in. As someone else already mentioned: ICMP has no state, and it does indeed seem to be true that the only way you can allow this using statefull filtering is if an ICMP packet is associated with a TCP or UDP packet ("session").

I conclude as much because when I add the rule
Code: 
allow out quick proto icmp
before the rule which also tracks the state of all outgoing data then everything works as expected.

Put differently: when I make sure that ipf doesn't perform statefull filtering for ICMP traffic then all works fine.

It's a bit specific, but it doesn't bother me. I'll update the status.
 
ShelLuser said:
Rest assured: I checked the handbook first and according to that page (section 31.5.12 called "Stateful filtering") it should also allow ICMP packets.

But when re-reading this it directly mentions: "IPF stateful filtering will also allow ICMP packets related to an existing TCP or UDP session.". If you start pinging a server I doubt you'll be sending related TCP or UDP packets.
Click to expand...
This is for things like ICMP destination port unreachable when a packet was sent to a closed UDP port. Or ICMP destination unreachable when it can't route the packets. These days it's more common to just drop the packets and not respond with anything.

Anyway, the more I read about ipf the more I have to admit that it seems dated.
Click to expand...
Yeah, it is. It hasn't seen much updates, especially in the last few years. Converting from IPF to PF should be relatively easy though, the syntax and the way they work is almost the same.
 
You must log in or register to reply here.
Back
Top