why pf nat two different ip address to one ip address with different port number?

s m sam.gh1986 at gmail.com
Tue Nov 3 06:15:39 UTC 2015

thank you Matt for your comprehensive answer. i have read man page for
pf.conf but i think rdr nor binat don't solve my problem. this is my

C1-----> switch-------->FreeBSD -------> C3

c1 and c2 wants to ping c3. in freebsd system i have put these lines in

table <1> { }
nat on 'gbeth2' from {} to any -> <1> round-robin sticky-address

i have assigned just one ip address to my table so i expect that when c1
pings c3 it nat to after that, when c2 pings c3, it drops since
there is no free ip address in my table to assign c2 but c2 nat to too with different port number.
i said static nat but it is not static nat it was my mistake. direction for
my nat is inside.
i hope it clears my scenario and what i want to do:)
i'm not familiar with pf so it's my appreciate if you help me to solve it.
thanks in advance

On Sun, Nov 1, 2015 at 3:16 PM, Matthew Seaman <matthew at freebsd.org> wrote:

> On 01/11/2015 06:26, s m wrote:
> > hello everybody
> >
> > i wanna nat my local addresses with pf but i have a strange problem. this
> > is my pf.conf file:
> >
> > table <1> { }
> > nat on 'gbeth2' from {} to any -> <1> round-robin
> sticky-address
> >
> >
> > i wanna have static nat with just one ip address( with these
> > rules i expect the first system which send packet to my freebsd system,
> nat
> > to and the second system do not nat since we have no free ip
> > address. but what is happened is totally different! the second one nat to
> > the same ip address but with different port number like this:
> >
> > all icmp* <>* ( ->
> > 0:0
> > all icmp * <>* ( ->
> > 0:0
> >
> > would you please tell me what is wrong with my pf.conf rules? how can i
> > prevent this? i want to nat just the first system which request for it
> and
> > ignore the request from the second system. it should be possible, isn't
> it??
> >
> > any comments or hints are appreciated.
> It's not clear from your description exactly what you are trying to
> achieve.
> Is the traffic you are trying to manage incoming or outgoing or both?
> By which I mean in what direction is the initial connection made? --
> obviously its useless to only handle packets going one way without
> dealing with the response packets that come back, but pf(4) deals with
> traffic very differently depending on the direction of the initial
> connection.
> NAT generally works with outgoing traffic -- from your lan with a
> private address range out to the internet in general.  It can hide a
> whole internal network behind a single IP address, and to do this it may
> use varying ephemeral port numbers on the NAT address to distinguish
> different traffic streams.  This behaviour appears to be not what you
> are expecting.
> Now, you mention 'static NAT' -- that terminology usually refers to a
> facility to allow connections across a NAT gateway in the reverse
> direction.  pf(4) certainly can do this, but uses a different keyword:
> 'rdr' (from ReDiRect) -- where people can connect to your public NAT
> address and have the traffic redirected to a server or servers inside
> your private address space.  Usually this is done for specific network
> ports, and you can have several different rdr's at once (so eg. you can
> send web traffic and e-mail to distinct internal servers.)
> (Then there's 'binat' (Bi-directional Network Address Translation) which
> I mention only for completeness -- this is a symmetric form of NAT
> between internal and external address blocks.  It has the property of
> never modifying port numbers (which NAT may do, and RDR always does.)
> binat is relatively uncommon: if you want to handle both incoming and
> outgoing traffic on a NAT gateway, it is more usual to have both 'nat'
> and 'rdr' rules in your pf.conf)
> All of these are suitable for relatively simple mappings -- no failover,
> no server healthchecks, no traffic weighting, no sticky sessions etc.
> etc.  If you need something more sophisticated, then look at the
> net/relayd port.  This can give pf(4) the capabilities of a fully
> featured load balancer.
>         Cheers,
>         Matthew

More information about the freebsd-questions mailing list