Re: nat on enc0

["Agarwal, Amit (Amit)" <agramit@avaya.com>]

Hi,
	First I would like to thank you for the efforts in solving this issue.
	Also I would like to explain my issue little bit more clearly.
	In my topology VPN device 2 should not have any knowledge of 10.10.10/24 subnet. VPN device 2 should not have to create IPSec SA for any subnet other than 15.15.15.15 as there may be other VPN devices which are also connecting to VPN device 2 and have the same private subnet as VPN device 1(10.10.10/24). Also VPN device 2 can not create any IPSec SA for 0/0 either for VPN device 1 as there are more VPN devices like VPN device 1.
	I could not understand what do you mean by acquire-based setup. Well I may be missing something here with your proposed solutions.
	If I can hack the isakmpd and SADB such that SPD will have entry for 10.10.10/24 but the SAs negotiated by isakmpd (not difficult to do) and used by SADB (not sure about this) will be for 15.15.15.15, my problem would be solved. Is it the same type of hack you proposed in solution 2? If yes please send me your patch.

thanks a lot,
Amit 

-----Original Message-----
From: Cedric Berger [mailto:cedric@berger.to]
Sent: Friday, June 20, 2003 12:31 PM
To: Agarwal, Amit (Amit)
Cc: tech@openbsd.org
Subject: Re: nat on enc0


Agarwal, Amit (Amit) wrote:

>Hi,
>	I have following topology and would greatly appreciate any help or references
>for the solution.
>
>	I am using tunnel mode for creating VPN between OpenBSD embedded VPN devices
>and would like to apply NAT on enc0 interface.
>
>	10.10.10/24--(Protected) ---VPN device
>1(Public)--------------Internet-------(Public)VPN device 2
>---(Protected)----20.20.20/24
>
>	I applied following NAT rules on the VPN device 1
>		@0 pass in quick on enc0 proto ipencap all
>		nat on enc0 inet from 10.10.10/24 to any -> 15.15.15.15 port 5000:65535
>
>	I would like to create VPN tunnels between above two VPN devices with
>protected members as 15.15.15.15 for VPN device 1 and 20.20.20/24 for VPN
>device 2.
>
>	The issue I have is as SPD lookup happens before NAT on enc0, I have to add
>10.10.10/24 subnet in SPD in order to forward those packets to enc0 interface.
>If I do that and start sending IP packets from 10.10.10/24 to 20.20.20/24
>subnet, the SAs are created for 10.10.10/24 subnet first. IP packet gets
>forwarded to enc0 interface and NAT is applied and packets are tunnels. In the
>return path an IPSec SA is negotiated by VPN device 2 for 15.15.15.15.
>
>	I only want to create tunnel for 15.15.15.15 and would like to apply NAT on
>enc0 interface (not on private interface as there may be more than one private
>interfaces where I may get packets destined for VPN and want to apply NAT so
>enc0 would be the best place to do that).
>
If you're using acquire-based setup, I don't know how to help you,
you will have to find by yourself. Apparently, you understand the 
problem correctly!

>	In ipsec man page there is a hint that special care needs to be taken for NAT
>on enc0 but does not give any details for special care.
>
The 2 solutions I implemented was:
  1) You can add a "dummy" entry mapping from 0/0 to 20.20.20/24 just in 
order to
  route the packet through the enc0 interface.
  2) What I did was to hack isakmpd to write 0/0 instead of 15.15.15.15 
when it
  write the spd into the kernel. I can send you that patch, but in both 
case was using
  isakmpd "old-style", with all the definitions in isakmpd.conf

>	From some email thread on netsys I got following suggestions for changing the
>code but would like to know if there is any better solution.
>
>		Original code:
>		if(packet match IPSec database) {
>			if(pf_test(enc0) != PASS) {
>				drop packet
>			}
>			else {
>				encrypt packet
>			}
>		}
>
>		New code:
>		pf_nat(enc0) // let's try
>		if(nat'd packet match IPSec database) {
>			if(pf_filter(enc0) != PASS) {
>				drop packet
>			} else {
>				encrypt packet
>			}
>		}
>		else {
>			pf_undonat(enc0)
>		}
>
I think this is one of the idea I had, but never got any feedback nor 
time to
implement/test it. I'm not sure it would work, but if you've time to 
play with
that idea, I'm very interrested! One of the problem is to make it fast for
packets that should not be encrypted.
Cedric