hey markus,
thanks for your reply.
no traffic on enc0 without the nat statement. i too suspect, that its
not nat which is giving me headaches. our_fw and ASP_peer auth using a
pre-shared key, if thats what you were asking. the tunnel gets
established without any glitches. at least isakmpd in debug mode shows
nothing unusal and our ASP confirmed that the tunnel is setup correctly
(no ipsecctl available since its a 3.7 box).
no matter where exactly i do the nat (be it on enc0 or our internal IF)
theres no traffic on enc0. as soon as i setup additional flows with
ipsecadm, packets vanish after entering the internal IF. i'm suspecting
that something with the flows is wrong. without them, our_fw is trying
to route the packets out of the external IF (no antispoof rules at the
moment).
using google turned up a few guys who were suggesting success on a
similiar setup, doing nat on enc0 (i. e.
http://archives.neohapsis.com/archives/openbsd/2004-05/0924.html).
Markus Wernig wrote:
greets
-WJ
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
nat on enc0 inet from 192.168.A.A/24 to B.B.B.B/8 -> 172.C.C.C
Hi <Realname not known>
What do you see if you don't use the nat statement? Do packets from
192.168 get sent to B.B over enc0? If not you still have some other
problem. How do you and ASP_peer authenticate? Check first if your
tunnels get established (ipsecctl -s all after the ping).
I'm no pf expert but from my understanding of flows I'd try to nat on
the incoming interface before encryption and routing take place.
I think that if you nat on enc0 you will be changing the packet's
payload and break the hash. (Not sure about that one - is there a
description of the packet flow through a pf/ipsec gateway anywhere?)
krgds /markus
-----BEGIN PGP SIGNATURE-----
iD8DBQFDksFE8BX/d8pVi/cRArkvAJsHhi+thVTiWfWXlTXLfCwb9W8VzwCgp7pB
IgqfOdMd2CzEaEZ4K1uCXNE=
=RDRl
-----END PGP SIGNATURE-----
