Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
From: Christoph Leser (Lesersup-logistik.de)
Date: Thu Aug 23 2007 - 12:29:44 CDT
I tried ( and failed ) to set up an IPSEC Tunnel to a LANCOM VPN Router in a
somewhat special constellation:
main mode is ok
quick mode negotiated successfully and established the following flow:
# ipsecctl -s flow
flow esp in from 172.17.0.0/16 to 172.17.7.50 peer a.b.c.d srcid
vpnsup-logistik.de dstid vpnborne.de type use
flow esp out from 172.17.7.50 to 172.17.0.0/16 peer a.b.c.d srcid abcx.y
dstid defu.v type require
here 172.17.0.0/16 is the private net at the remote site, a.b.c.d is the
remote internet address, the ID parmeters of main mode are of type user_fqdn.
What is special in the above configuration is that I was asked to use an
address from the remote private net range ( 172.17.7.50 ) as my local id
parameter in quick mode ( instead of my own local address or local net ).
This looks like a typical dial-in setup, where the dial in client is given an
address in the remte target network, and the remote router acts as proxy for
this address. I do not know whether this is a valid setup for IPSEC, but the
person on the remote site told me that he uses this setup for his ( windows )
road worrier clients.
If this is valid and can be done on openBSD, what is needed to complete this
As shown above, the flow gets established, but ping 172.17.0.1 fails with 'no
route to host'.
It seems that I'm lacking basic understand of the relationship between 'ipsec
flows' and routing.