[Openswan Users] openSWAN to Cisco IOS

[Christian Brechbühler]

On 11/26/06, Paul Wouters <paul at xelerance.com> wrote:

>
> From man ipsec.conf:
>
>        leftsourceip
>               the IP address for this host to use when
> transmitting  a  packet
>               to the other side of this link. Relevant only locally, the
> other
>               end need not agree. This option
> is  used  to  make  the  gateway
>               itself  use its internal IP, which is part of the
> leftsubnet, to
>               communicate to the rightsubnet or right. Otherwise, it
> will  use
>               its  nearest  IP  address,  which is its public IP address.
> This
>               option is mostly used when
> defining  subnet-subnet  connections,
>               so  that  the  gateways can talk to each other and the
> subnet at
>               the other end, without the need to build additional
> host-subnet,
>               subnet-host and host-host tunnels.


Thanks for the quote!  I searched, but leftsourceip is not documented in the
2.4.4 man page.  Do you know in which release it was implemented?
So if the VPN gateway has internal IP 10.0.0.1 and is "left", setting
"leftsourceip=10.0.0.1" should address the issue.  Indeed after careful
rebuilding (--down on both sides first), tracepath gets through:
vpn$ tracepath -n 192.168.2.2
 1?: [LOCALHOST]     pmtu 1448
 1:  10.0.0.1          0.057ms pmtu 1418
 1:  192.168.2.2      35.004ms reached
     Resume: pmtu 1418 hops 1 back 1
 (I had to stop iptables on 192.168.2.2 -- gotta sort this out.)

Your gateway's public ip is not covered in the "subnet-subnet" tunnel, so it
> will not get encrypted with IPsec. On top of that, because there is a
> connection between the two gateways, they will refuse to communicate in
> the
> clear, so your packet gets dropped. This is the easiest fix, and makes
> sure
> all your communicatin between subnets and gateways happens encrypted.


Cool, I keep trying that.

Adding SNAT in the mix makes things a bit more complex. Ensure to operate
> the SNAT on an interface before it hits the IPsec server, so that the
> two don't bite. (or try the ipsec+snat from 2.6.17+ but someone else
> should
> write a good description on how to do that, I've never done it myself
> since
> I mostly use klips)
>
> Paul
>

Yes, the connection vpn...lithium is avoiding the SNAT to first make sure
everything else (particularly routing) works well.

Thanks again for all your help!
/Christian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20061126/0c0bdc3b/attachment.html