NAT + IPF

From: steve b (moxie@angry-youth.org)
Date: Wed Aug 21 2002 - 16:39:05 EDT


Greetings:

I'm having difficulty getting two machines talking with IPSec when
packets from the originating host are being NATed (via IPF) from an
internal network. I've been working on the following problem
for the better part of a day and haven't been able to get very far. Here
is my network setup:

[client1] <--> [sol1] <--IPSec Encrypted--> [sol2]

sol1 and sol2 are Solaris 8 Netra boxes:
SunOS msdev8 5.8 Generic_108528-15 sun4u sparc SUNW,UltraAX-i2

sol1 is running ip-fil3.4.28 and NATing for client1. This is working
fine, and client1 can reach sol1 as well as just about every other machine
that sol1 can reach except one: sol2.

Looking at sol2:/var/adm/messages, I see the following:

Aug 21 15:18:20 sol2 ip: [ID 177200 kern.error] ip_fanout_tcp_listen:
Policy Failure for the incoming packet (not
secure); Source sol1, Destination sol2

Indeed, a snoop on sol2 shows that packets that originated from client1
and are NATed through sol1 are showing up at sol2 unencrypted:

sol1 -> sol2 TCP D=22 S=1034 Syn Seq=2799349106 Len=0 Win=16384 Options=<mss 1460,nop,wscale..>

*However*, when SSHing directly from sol1 to sol2, things work
just as the IPSec policy states that they should:

auth1 -> auth2 ESP SPI=0x5000 Replay=9
      auth2 -> auth1 ESP SPI=0x5001 Replay=2

My ipsecinit.conf rules are quite simple:

{ daddr sol2 saddr sol1 }
apply { encr_algs 3des encr_auth_algs sha1 sa shared}

{ saddr sol2 daddr sol1 }
permit {encr_algs 3des encr_auth_algs sha1}

[And visa versa for the other side]

ipnat.conf on sol1 is also VERY simple:

map eri0 192.168.1.0/24 -> (external address)/32

Does anyone have any ideas what might be going on here? My only guess is
that the IPsec layer is getting the packet BEFORE it's being NATed, which
is why it's not being IPSec-atized. If this is the case, is there
anything I can do to make this work? If this *isn't* the case, what's going
on? I'm ready to pull my hair out!

Thanks for any help you can provide.
Steve
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers



This archive was generated by hypermail 2.1.7 : Wed Apr 09 2008 - 23:24:49 EDT