[strongSwan] Testing ISAKMP datagrams (unanswered ARP requests)

[strongswan at encambio.com]

Hello list,

On Wed., Feb. 06, 2013, strongswan at encambio.com schrieb:
>On Tues., Feb. 06, 2013, Andreas Steffen wrote:
>>On 02/05/2013 10:45 PM, strongswan at encambio.com wrote:
>>> My goal is building a IPv4 IPSec tunnel using IKEv1.
>>> 
>>>   Ubuntu 12.10 GNU/Linux AMD64
>>>   Strongswan 4.5.2
>>> 
>>If you change the setting in ipsec.conf to auto=start then
>>
>>  ipsec start
>>
>>will cause pluto to automatically negotiate the "here" connection
>>and with auto=route
>>
>>  ipsec start
>>
>>will install a trap in the kernel and the first IP payload packet
>>in direction to rightsubnet=192.168.1.0/24 will trigger
>>the IKE negotiation.
>>
Seems this feature is buggy on my platform. While auto=add and later
ipsec up <conn> correctly sets up the tunnel, auto=route and ping
<host-in-rightsubnet> causes some pluto(8) activity (writes to log)
but in the end traffic is not forwarded.

>Excellent answer, thank you. Finally pluto is encapsulating IP and
>sending it to the 'right' place, but there's a new problem:
>
>[...]
>
>  192.168.1.1$ tcpdump -i lan  # the racoon computer's LAN subnet
>  18:22:32.673240 IP 192.168.1.55.39347 > 192.168.1.88.80: Flags [S], seq 3091785373, win 14600, options [mss 1460,sackOK,TS val 5418801 ecr 0,nop,wscale 7], length 0
>  18:22:32.678002 ARP, Request who-has 192.168.1.55 tell 192.168.1.88, length 46
>
>PROBLEM
>
solved... The racoon(8) server was giving out %modeconfig IPs in
its own LAN space, causing other LAN attached hosts to query the
interface for ARP values assuming that the IPSec connected host
was participating in the same LAN segment.

SOLUTION

Set the IP described by %modeconfig to not be inside the foreign
LAN subnet.

Regards,
Michael