Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 24 Sep 2006 10:12:44 +0100
From:      Matthew Seaman <m.seaman@infracaninophile.co.uk>
To:        Peter Schuller <peter.schuller@infidyne.com>
Cc:        freebsd-questions@freebsd.org
Subject:   Re: pf + ipv6 + keep state - any known issues?
Message-ID:  <45164C0C.5010406@infracaninophile.co.uk>
In-Reply-To: <200609240036.12322.peter.schuller@infidyne.com>
References:  <200609240036.12322.peter.schuller@infidyne.com>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig77B6164B8715D84D4EC26350
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

Peter Schuller wrote:
> Hello,
>=20
> I am using pf on a 6.1 machine. I have a tunneling interface (gif0) for=
 my=20
> IPv6 feed. The problem I am having is connecting to myself in spite of =

> firewalling.
>=20
> I am allowing traffic on port 22 to my public ipv6 address. I am also a=
llowing=20
> all outgoing traffic on the tunneling interface, with 'keep state'.
>=20
> ping6:ing myself works, but connecting to port 22 does not. The intial =
SYN=20
> gets through and is responded to by an ACK, but that ACK is seemingly=20
> dropped. This inspite of the fact that 'pfctl -s state' shows a tracked=
=20
> connection for the relevant port pair.
>=20
> I can work around it by allowing all packets from my own IP on the tunn=
eling=20
> interface, but as far as I know this should not be required. That is,=20
> connection tracking should be working even for local connections on a=20
> particular interface - correct?
>=20
> Note that connecting to port 22 works perfectly from outside IP:s (I ha=
d=20
> someone external verify this) without any special casing of the rules. =
That=20
> is, I only have the usual rules for allowing the incoming packets to po=
rt 22,=20
> and the rule allowing outgoing packets with 'keep state'. The fact that=
 this=20
> allows successful establishment to port 22 by an external party suggest=
s to=20
> me that I have not made some trivial misstake in the rule - yet connect=
ions=20
> to myself do not work.
>=20
> My question is whether there are any known issues that this sounds like=
 - or=20
> of course if there is some reason why this is not supposed to work by d=
esign.

Are you using antispoofing rules on your external interface?  If you've g=
ot
something like this in your ruleset:

   antispoof log quick for $ext_if

Then it will expand into a series of rules containing the following when =
you load
them:

block drop in log quick on ! em0 inet from 12.34.56.72/29 to any

Where 12.34.56.72/29 is the address of the network your external interfac=
e
(em0) is attached to.  (Although the example I show is for IPv4, exactly =
the
same applies for IPv6) End result is that you cannot connect to a service=

listening on your external IP from the box itself, because that does not
result in inbound packets traversing the em0 interface.  And it's a 'quic=
k'
rule, so you can't override it by adding a more specific rule later in th=
e
ruleset.

In general, use antispoof for the loopback as a standard part of any rule=
set
you write.  Antispoof on other interfaces should be considered carefully =
and
only applied where necessary.

	Cheers,

	Matthew

--=20
Dr Matthew J Seaman MA, D.Phil.                       7 Priory Courtyard
                                                      Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey         Ramsgate
                                                      Kent, CT11 9PW


--------------enig77B6164B8715D84D4EC26350
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFFkwS8Mjk52CukIwRCFHSAJ9Rcl+cwoYgvWrr/uE9gUajpeulnQCfdt4l
n8lwxDyMuUdHSrXRqD/DN3U=
=NhqM
-----END PGP SIGNATURE-----

--------------enig77B6164B8715D84D4EC26350--



Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?45164C0C.5010406>