Re: nat on enc0

[Cedric Berger <cedric@berger.to>]

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