I have encountered and interesting discrepancy in the behavior of ipf vs pf, and I would like to find a way to make pf work like ipf in this specific circumstance if that is possible.
A client has a SIP gateway that communicates with a server through a FreeBSD router/firewall device, and the communication is NAT'ed by the FreeBSD device. This gateway seems to not know about NAT, and the client is not using STUN.
There are two versions of the FreeBSD device. One uses ipf as the firewall, and the other uses pf as the firewall. The kernel is a modified FreeBSD 8.4 kernel, which is descended from a m0n0wall version. The ipf firewall contains m0n0wall enhancements; the pf firewall does not...which actually gives me an idea that I will investigate, but that is for later.
The ipf version of the FreeBSD device has a rule in it like this (written in PHP):
The pf version has the corresponding rule:
In both devices the rangelow and rangehigh variables are set to 1024 and 64535 respectively.
When the device that uses ipf is in place, the client's SIP gateway is able to make a connection with the server and phone calls pass. When the device that uses pf is in place, the gateway is unable to obtain a BIND with the server, and traffic does not pass.
Pulling pcaps of the traffic reveals that when pf NAT's the outgoing traffic, it establishes a random high port for the NAT'ed traffic, which is the behavior you would expect. When ipf NAT's the outgoing traffic, it preserves the port provided to it by the incoming traffic from the SIP gateway and after NAT posts that port as the reply port for the server traffic. This is why the device using ipf allows the connection while the device using pf doesn't allow the connection; the server is responding to the port given by the SIP gateway and that port is valid with ipf and invalid with pf.
I am actually inclined to label this a bug in ipf. Either that, or ipf is smart enough to recognize SIP and deliberately do this in order to simplify the problems associated with SIP and NAT (which is an idea that I must investigate, looking at the m0n0wall enhancements).
In any event, is there a way to make pf behave this way? It would be quite convenient if it could be done, but would require specifying that the reply port must be preserved across NAT.
A client has a SIP gateway that communicates with a server through a FreeBSD router/firewall device, and the communication is NAT'ed by the FreeBSD device. This gateway seems to not know about NAT, and the client is not using STUN.
There are two versions of the FreeBSD device. One uses ipf as the firewall, and the other uses pf as the firewall. The kernel is a modified FreeBSD 8.4 kernel, which is descended from a m0n0wall version. The ipf firewall contains m0n0wall enhancements; the pf firewall does not...which actually gives me an idea that I will investigate, but that is for later.
The ipf version of the FreeBSD device has a rule in it like this (written in PHP):
Code:
$portmaprule = "map $if $src $dst -> {$tgt} portmap tcp/udp $rangelow:$rangehigh\n";The pf version has the corresponding rule:
Code:
$portmaprule = "nat on $if proto {tcp,udp} from $src to $dst -> ({$tgt}) port $rangelow:$rangehigh\n";In both devices the rangelow and rangehigh variables are set to 1024 and 64535 respectively.
When the device that uses ipf is in place, the client's SIP gateway is able to make a connection with the server and phone calls pass. When the device that uses pf is in place, the gateway is unable to obtain a BIND with the server, and traffic does not pass.
Pulling pcaps of the traffic reveals that when pf NAT's the outgoing traffic, it establishes a random high port for the NAT'ed traffic, which is the behavior you would expect. When ipf NAT's the outgoing traffic, it preserves the port provided to it by the incoming traffic from the SIP gateway and after NAT posts that port as the reply port for the server traffic. This is why the device using ipf allows the connection while the device using pf doesn't allow the connection; the server is responding to the port given by the SIP gateway and that port is valid with ipf and invalid with pf.
I am actually inclined to label this a bug in ipf. Either that, or ipf is smart enough to recognize SIP and deliberately do this in order to simplify the problems associated with SIP and NAT (which is an idea that I must investigate, looking at the m0n0wall enhancements).
In any event, is there a way to make pf behave this way? It would be quite convenient if it could be done, but would require specifying that the reply port must be preserved across NAT.
