Hi,
I have two Redhat linux PC's with the latest Fedora core installed. I want to set up the following network:

eth1 eth0
10.10.10.x------Srvr1----192.168.1.1------+
|
| IPSec Branch Office tunnel.
|
11.11.11.x------Srvr2----192.168.1.2------+
eth1 eth0

I want to turn NAT on eth0 of both Srvr1 and Srvr2.

So all traffic from the 10.10.10.x/24 network is going to get nated to 192.168.1.1 and sent over the network and all traffic from 11.11.11.x/24 is going to get nat'ed to 192.168.1.2

I want the traffic to get NAT'ed and then to go through the IPSec tunnel

On Srvr1 I set up the following SPDs:

192.168.1.2[any] 192.168.1.1[any] any
in ipsec
esp/tunnel/192.168.1.2-192.168.1.1/require
created: Aug 23 17:29:49 2005 lastused:
lifetime: 0(s) validtime: 0(s)
spid=1568 seq=2 pid=20042
refcnt=1
192.168.1.1[any] 192.168.1.2[any] any
out ipsec
esp/tunnel/192.168.1.1-192.168.1.2/require
created: Aug 23 17:29:49 2005 lastused:
lifetime: 0(s) validtime: 0(s)
spid=1561 seq=1 pid=20042
refcnt=1
192.168.1.2[any] 192.168.1.1[any] any
fwd ipsec
esp/tunnel/192.168.1.2-192.168.1.1/require
created: Aug 23 17:29:49 2005 lastused:
lifetime: 0(s) validtime: 0(s)
spid=1578 seq=0 pid=20042
refcnt=1

So I then try a simple ping from Srvr1:
ping -I eth0 192.168.1.2
I can see IPSec trying to set up the tunnel, but no ISAKMP packets are sent over the network. Why is this? Is it because the 192.168.1.2 is in the Remote Accessible Network list? i.e. it can't send the ISAKMP packet as it needs to set up the IPSec tunnel to do this (ala chicken and the egg style!!!)

Is there any way to force packets through the SPDs and out?

Thanks in advance for your responses,
Paul McDaid.

The connection is from eth0 to eth0 192.168.1.1 -> 192.168.1.2. The graphic didn't come out correctly in the original post.

Insert the graphic as and use the "review" function to see it works before posting it..

I did some searching on the web today and found this in the following site:

http://www.mikrotik.com/docs/ros/2.8/ip/ipsec

----------------------
IKE Traffic
To avoid problems with IKE packets hit some SPD rule and require to encrypt it with not yet established SA (that this packet perhaps is trying to establish), locally originated packets with UDP source port 500 are not processed with SPD. The same way packets with UDP destination port 500 that are to be delivered locally are not processed in incoming policy check.
---------------------

This seems to be the problem that I'm experiencing. Does anyone know of any patches to the IPSec code that will skip over the SPD for ISAKMP packets (port 500)?

When you set up IPSEC you will have a separate interface name for the tunnel.
You will need to set up static routes to say where to find each remote from each source so that packets are routed down the tunnel correctly.
This means you don't need to NAT down the ipsec tunnel interface.

Hi Peter,
The FreeBSD/KAME approach is to use SPD and not static routes to force the traffic down the tunnel. This means that the SPD overrides the routes.

I can use a simpler example where I set the local and remote Accessible networks equal to the endpoint ddresses:


Hi Peter,
The FreeBSD/KAME approach is to use SPD and not static routes to force the traffic down the tunnel. This means that the SPD overrides the routes.

I can use a simpler example where I set the local and remote Accessible networks equal to the endpoint addresses:

|server1|---------------------------|Server2|
192.168.1.1


Server1 eth0 = 192.168.1.1
Server2 eth0 = 192.168.1.2

On Server 1:
Local Endpoint Address = 192.168.1.1
Remote Endpoint Address = 192.168.1.2
Local Accessible Network = 192.168.1.1/255.255.255.255
Remote Accessible Network = 192.168.1.2/255.255.255.255

Server 2 has the settings swapped.

So if I ping from Server1 to Server2. Server1 tries to set up an IPSec tunnel by trying to send it's first ISAKMP packet. However the ISAKMP packet never gets out as it matches the local/remote accessible network (192.168.1.1/192.168.1.2) so the tunnel never gets established.

This is a common routing problem with VPNs when they have the same subnet at each end..

The long term solution is to change subnet numbers at one site..

A short term solution is to add a second virtual ip number to the pcs receiving the vpn traffic. eg 192.168.3.x at one site & 192.168.4.x at the other..