isakmpd, preventing subnet clashing using NAT

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

isakmpd, preventing subnet clashing using NAT

OpenBSD-List
hello people,
i'm trying to setup a vpn between us and our ASP. they've assigned us
"their own" private rfc11918 addresses, from which they want us to
connect from. basically our topology looks like depicted below:

our_internal <--> our_fw <--> internet <--> ASP_peer <--> ASP_internal

"our_internal" is 192.168.A.A/24
"our_fw" with 82.x.x.x on its external IF, running openbsd 3.7 release
the "ASP_peer" with 193.x.x.x on its external IF (some cisco vpn
concentrator - which i've no access to)
"ASP_internal" is B.B.B.B/8
they want us to connect from 172.C.C.C/30

the tunnel between our_fw and ASP_peer is established and confirmed by
our ASP. since our_fw would only route packets from 172.C.C.C/30 to
B.B.B.B/8 i did setup additional flows using ipsecadm:

ipsecadm flow -addr B.B.B.B/8 192.168.A.A/24 -dst ASP_peer -proto esp
-in -use
ipsecadm flow -addr 192.168.A.A/24 B.B.B.B/8 -dst ASP_peer -proto esp
-out -require


the flows are being showed correctly when doing "netstat -rf encap".

B/8               0     172.C.C.C/30       0     0     193.x.x.x/50/use/in
B/8               0     192.168.A/24       0     0     193.x.x.x/50/use/in
172.C.C.C/30      0     B/8                0     0    
193.x.x.x/50/require/out
192.168.A/24      0     B/8                0     0    
193.x.x.x/50/require/out


in pf.conf i've a line saying:

nat on enc0 inet from 192.168.A.A/24 to B.B.B.B/8 -> 172.C.C.C

ping from our_internal to a machine in ASP_internal and listeing with
"tcpdump -ni $int_if" shows icmp echo request coming in on the internal
IF. listening on enc0 shows nothing but silence. "tcpdump -ni $ext_if
esp" shows silence too. listeing on pflog0 shows packets entering our_fw
on the internal IF. it looks like the packets simply disappear after
entering our_fw.
at the moment our_fw does pass everything and keeps state.

also, occasionally i'm getting these from isakmpd:

transport_send_messages: giving up on message 0x3c069500, exchange
Peer-ASP_fw
transport_send_messages: either this message did not reach the other peer
transport_send_messages: or the responsemessage did not reach us back
(tell me news...)

i know doing nat on enc0 and generally screwing-up VPNs with NAT doesnt
seem to be a very good idea, but it looks like i havent got other
options at the moment. please let me know if any additional infos are
needed.

any help/hints/suggestions would be greatly appreciated.

Reply | Threaded
Open this post in threaded view
|

Re: isakmpd, preventing subnet clashing using NAT

Markus Wernig
-----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-----


--
Markus Wernig
Unix/Network Security Engineer - CISSP, CCSA
GPG: CA558BF7
http://xfer.ch
---------------------------------------------
Linux User Group Bern - http://lugbe.ch
---------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: isakmpd, preventing subnet clashing using NAT

OpenBSD-List
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-----