Date: Sun, 1 Nov 2015 11:46:03 +0000 From: Matthew Seaman <matthew@FreeBSD.org> To: freebsd-questions@freebsd.org Subject: Re: why pf nat two different ip address to one ip address with different port number? Message-ID: <5635FB7B.1070901@FreeBSD.org> In-Reply-To: <CAA_1SgE94RRFVPbVPfPEA2z9hGCVqjv0Zix=7cRCxQySUkhM9w@mail.gmail.com> References: <CAA_1SgE94RRFVPbVPfPEA2z9hGCVqjv0Zix=7cRCxQySUkhM9w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--0aGJENvd9aqLW7OhcdwxCRtVs8fqudh5B
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
On 01/11/2015 06:26, s m wrote:
> hello everybody
>=20
> i wanna nat my local addresses with pf but i have a strange problem. th=
is
> is my pf.conf file:
>=20
> table <1> { 20.3.3.10 }
> nat on 'gbeth2' from { 10.3.3.0/24} to any -> <1> round-robin sticky-ad=
dress
>=20
>=20
> i wanna have static nat with just one ip address(20.3.3.10). with these=
> rules i expect the first system which send packet to my freebsd system,=
nat
> to 20.3.3.10 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:
>=20
> all icmp* 20.3.3.10:48401 <http://20.3.3.10:48401>* (10.3.3.2:27943) ->=
> 20.3.3.1:48401 0:0
> all icmp *20.3.3.10:58435 <http://20.3.3.10:58435>* (10.3.3.1:3706) ->
> 20.3.3.1:58435 0:0
>=20
> 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??
>=20
> 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
--0aGJENvd9aqLW7OhcdwxCRtVs8fqudh5B
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2
iQJ8BAEBCgBmBQJWNfuBXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NTNBNjhCOTEzQTRFNkNGM0UxRTEzMjZC
QjIzQUY1MThFMUE0MDEzAAoJELsjr1GOGkATuPcQAKTxoIw7QX9IYz1PGr6jWAus
U0PHqygPziAfpgc2JLwGLlvuT+IFOxNrnxOHWhFDSOsr/nE5Ov+cXScRxctjhi1J
qoO5sg3mHsNBpgu9lr5T5ciScVVGDLvA9GeVXaLaLM9nL8BQNojIdrKd5DzK8U4K
aS91zuevv873IAYfeuyHE3f1nyCKc3lOTEo6re6DlAG/JXkKSHlaBVz4OMfY2wXS
dY72DGzTK8gVI+dMBFYevqxSdrNAwuP3UNKrPrVDa/Pd7+zcxY2ztmmwZziVdGFK
OpTiUmFokdqK0o2q2O3KV3+RIodhvG1pAx8hoC77XY79FzvfeVXFiqh5sr/kyPPx
skz3k9PBRWLS39NXEkZQ2BCh85DYk9yjtVCc360GhJ4NHYVW0N3yTc2KEBtiIy56
6NEeXPs2U6jKY4YL2+FPp60bEUi9fGdqVV7slzz6h+rkY7qma6KldsPe2AOsFGCB
DUfgEW5+seIFQMWKc3ehxmkKm8R21zc6cyGV/d1Lk+qlhCvKVUD4j1cnAaycGVSA
bYRFX5xy9en3S3bsk4RhK+bsfAIOKjmGYQjl6QYxIAJ8iGkZ9eB2mN3Vm6i5tUP4
jli4B/HvfBLNJto2NzJFIOjaN78lQOfhgWoMjrtyCW85enJNjYsyon8v+j7r6ljH
l9IrH2M/qnEFjsYpQjUj
=7wzI
-----END PGP SIGNATURE-----
--0aGJENvd9aqLW7OhcdwxCRtVs8fqudh5B--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5635FB7B.1070901>