On 8/23/07, Christoph Leser <[EMAIL PROTECTED]> wrote:
> Hello,
>
> 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
> [EMAIL PROTECTED] dstid [EMAIL PROTECTED] type use
> flow esp out from 172.17.7.50 to 172.17.0.0/16 peer a.b.c.d srcid [EMAIL
> PROTECTED]
> dstid [EMAIL PROTECTED] 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
> setup?
>
> As shown above, the flow gets established, but ping 172.17.0.1 fails with 'no
> route to host'.
Did you try "ping -I 172.17.7.50 172.17.0.1" ?
Without specifying the outgoing interface with -I, you'll end up
trying to reach 172.17.0.1 through the default route.
>
> It seems that I'm lacking basic understand of the relationship between 'ipsec
> flows' and routing.
I guess you can add more flows to have the 172.17/16 network reachable
from your normal interface. I would try to add the following flow:
ike esp from egress to 172.17/16 peer a.b.c.d srcid ...
HTH
-martin
