On 04/04/2012 08:23 PM, Girish Venkatachalam wrote:
# ipsecctl -sa -v
FLOWS:
flow esp in from 10.1.23.0/24 to 192.168.1.0/24 peer 173.167.82.52 type
require
flow esp out from 192.168.1.0/24 to 10.1.23.0/24 peer 173.167.82.52 type
require
flow esp in from 173.167.82.52 to 59.99.242.167 peer 173.167.82.52 type
require
flow esp out from 59.99.242.167 to 173.167.82.52 peer 173.167.82.52 type
require
SAD:
esp tunnel from 173.167.82.52 to 59.99.242.167 spi 0xbeefdead auth
hmac-sha1 enc aes
sa: spi 0xbeefdead auth hmac-sha1 enc aes
state mature replay 0 flags 4
lifetime_cur: alloc 0 bytes 0 add 1333585275 first 0
address_src: 173.167.82.52
address_dst: 59.99.242.167
esp tunnel from 59.99.242.167 to 173.167.82.52 spi 0xdeadbeef auth
hmac-sha1 enc aes
sa: spi 0xdeadbeef auth hmac-sha1 enc aes
state mature replay 0 flags 4
lifetime_cur: alloc 0 bytes 196 add 1333585275 first 1333585277
address_src: 59.99.242.167
address_dst: 173.167.82.52
lifetime_lastuse: alloc 0 bytes 0 add 0 first 1333585277
I cannot ping between 192.168.1.50 and 10.1.23.2
Possibly just a routing issue (since the tunnels seem to be
established). See this thread:
http://comments.gmane.org/gmane.os.openbsd.misc/192986
It's kind of counter intuitive to have to specify a separate route for
a tunnel, since it is adding no real information for the system to
use, but it looks like it's a peculiarity of the current implementation.
- Aner
