# (IPF) Allowing ICMP from a specific IP address



## ShelLuser (May 29, 2013)

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:


```
## 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:


```
[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.


----------



## throAU (May 29, 2013)

Whilst I'm no PF expert...


ICMP is not a stateful protocol.


----------



## kpa (May 29, 2013)

It is not but it can be treated as stateful by a packet filter the same way UDP can be.


----------



## wblock@ (May 29, 2013)

PF can use keep state on ICMP.  IPF... no idea.


----------



## kpa (May 29, 2013)

Try the same with pf(4), there may be some oddities with IPF and vtnet(4) drivers. IPF has been in disrepair for quite a while compared to the two other firewall solutions of FreeBSD.


----------



## ShelLuser (May 29, 2013)

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.


----------



## ShelLuser (May 29, 2013)

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 
	
	



```
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.


----------



## SirDice (May 29, 2013)

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.


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.


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.


----------

