Re: [Ipsec-tools-devel] DNAT IPSec

[Victor B. <Vic...@qu...>]

Hi Tom,

It seems you're trying to use SA policies that don't quite match the
setkey policies. You are putting the NAT box's IP in your setkey
policies, in order to trick the routing stack on the clients. There is
no need to do this and it introduces a layer of obscurity into the
system. In your subsequent email to the list you note "Why should I
implement DNAT for the encrypted traffic when I already created policies
for host-to-host communication?" - I don't think you have quite created
such a policy. At the least, you are doing a somewhat non-standard usage
of setkey and SA policies that either surpasses my understanding of the
subject, or will not work as you intend.

What I would do is:
* Set up policies using only the IP addresses of the clients, A and B,
without the NAT box. Namely, change:

sainfo address 192.168.0.101 any address 192.168.0.200 any {

to

sainfo address 192.168.122.100 any address 192.168.0.200 any {

Also, change your setkey lines to what I wrote in my original message.

* With regard to NAT rules, I'm no longer sure you need them at all. On
the NAT box add the following routes (assuming that it has eth0 on
192.168.0.x side and eth1 on the 192.168.122.x side):
ip route add 192.168.122.100 dev eth1 
ip route add 192.168.0.200 dev eth0 
<note: these should already exist>

On client A add:
ip route add 192.168.122.100 via 192.168.0.101

On client B add:
ip route add 192.168.0.200 via 192.168.122.1
<assuming 192.168.122.1 is the IP of the NAT box on this network>

With this setup, you may not even need NAT traversal in racoon.

An alternative is to try to pursue the non-standard method you have set
up but after re-examining it I am convinced of the possibility that
insanity lies down that path ;) 

(In answer to your question, you could set up some NAT rules on client
192.168.122.100 in your existing setup, that mark incoming ESP packets,
then DNAT the marked packets to 192.168.122.100, but I'm still not
convinced of the need to NAT anything here. NAT exists for the situation
where you cannot control the routing table of one of the clients - e.g.
if we are talking about servers on the wild internet)

In answer to your further question in your second email, I'm not
reachable by IRC at this time, because it's 3AM local time and I want to
sleep ;)

Cheers,

V

-----Original Message-----
From: Tom Tonk [mailto:tn...@ar...] 
Sent: Saturday, 26 April 2008 1:42 AM
To: Victor Bajanov
Subject: Re: [Ipsec-tools-devel] DNAT IPSec

Hi Victor,

Victor Bajanov wrote:
> You have two options:
> 1) Create a tunnel directly between the two clients, A and B, and set
up
> ROUTING on clients A and B, and some DNAT and SNAT rules on the NAT
box,
> to move the encrypted traffic appropriately. Racoon would run on the
two
> clients and need not run on the NAT box at all. However, you would
need
> NAT-T enabled as SNAT would "break" ESP packets without it (I'm not
100%
> sure on this point - someone with deeper understanding feel free to
> chime in). 

Actually I'm using 2 NAT rules:

1) for ESP packets to the client
2) for UDP 500/4500 packets to the client

what kind of other rules are required on the nat box?

Thanks for your answer, that was exactly what I was looking for.

Greetings,
Tom