[Openswan Users] Trying to get basics down

[Nick Howitt]

I had/have a similar thing. I asked Paul Wouters many moons ago and he 
said if you have net.ipv4.ip_forward = 1
then don't worry about the output of ipsec verify. Also if you do not 
need NAT-T what is the point of adding nat_traversal=yes? Again, just 
ignore ipsec.verify for this one.

Regards,

NIck

On 19/05/2011 17:52, Neal Murphy wrote:
> On Thursday 19 May 2011 09:33:12 Chris Ditri wrote:
>> Okay... according to tcpdump, the tunnel has been established:
>>
>> tcpdump -n -i eth0 |grep -i esp
>> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
>> listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
>> 09:26:34.689663 IP 10.5.5.126>  10.5.5.134:
>> ESP(spi=0x7e2eb1cb,seq=0x24), length 148
>> 09:26:34.697211 IP 10.5.5.134>  10.5.59.126:
>> ESP(spi=0x0209e228,seq=0x17), length 148
>> 09:26:34.697530 IP 10.5.5.126>  10.5.5.134:
>> ESP(spi=0x7e2eb1cb,seq=0x25), length 100
>>
>> ... but I'm still not sure why I'm getting this when I try to verify:
>>
>> Pluto listening for NAT-T on udp 4500                           [FAILED]
> Add 'nat_traversal=yes' after the 'protostack=netkey' line. That should allow
> openswan to use NAT-T if/when it determines it needs to and make the failure
> go away.
>
>> Two or more interfaces found, checking IP forwarding            [FAILED]
> 'cat /proc/sys/net/ipv4/ip_forward' just to verify that it's being set. Of
> course, seeing packets routed through the system is probably solid evidence,
> too. ;) Is there a possibility that openswan cannot access what it checks for
> forwarding? Otherwise, can't help with this one.
> _______________________________________________
> Users at openswan.org
> http://lists.openswan.org/mailman/listinfo/users
> Micropayments: https://flattr.com/thing/38387/IPsec-for-Linux-made-easy
> Building and Integrating Virtual Private Networks with Openswan:
> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155