[Openswan Users] openSWAN to Cisco IOS

[Christian Brechbühler]

On 11/25/06, Paul Wouters <paul at xelerance.com> wrote:
>
> On Fri, 24 Nov 2006, Christian Brechbühler wrote:
>
> > I'll let you know if I get it to work.  But even without SNAT, I get
> this
> > weird situation (not serious, but may be the same issue):  When lithium
> > establishes an IPsec tunnel to the vpn gateway, connections that lithium
>
> > initiates (ping, ssh, traceroute, http) work fine.  Any connection to
> > lithium that the gateway initiates fails.  Is this normal?  I suspect
> NO,
> > and the firewall on the gateway may be ruining things.
>
> Use leftsourceip=firewallinternalIP


Hi Paul,

Thank you!  I haven't gotten it to work yet.  Can you spell this out a bit
more, please?

I'd like to tell you first about a connection between two linux/openswan
hosts, which doesn't use SNAT but exhibits the same routing problem.
(Outside IPs changed out of paranoia.)
Here's the layout; the connection is between "lithium" and "vpn"

"lithium" 192.168.2.2 (laptop) -- Linux Openswan U2.4.4/K2.6.9-1.11_FC2(netkey)
|
belkin inside 192.168.2.1 (home router/NAT/firewall)
belkin outside 24.61.22.33 (UDP port 500  forwarded to lithium)
|
internet (ISP Comcast)
...
internet (ISP Speakeasy)
|
"vpn" outside 66.92.44.163 <http://66.92.44.55> -- Linux Openswan
U2.4.4/K2.6.11-gentoo-r5
(netkey)
"vpn" inside 10.0.0.1
|
10.0.0.0/24 private network

ipsec.conf on lithium:
version 2.0     # conforms to second version of ipsec.conf speci

config setup
    nat_traversal=yes
    virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16<http://10.0.0.0/8,%25v4:192.168.0.0/16,%25v4:172.16>
    interfaces=%defaultroute
    plutodebug="control parsing"

conn %default
    keyingtries=1
    compress=yes
    authby=rsasig
    right=%defaultroute
    rightcert=lithium.pem
    leftrsasigkey=%cert
    auto=add

conn boston
    leftsubnet=10.0.0.0/24
    left=66.92.44.163 <http://66.92.44.55>
     leftid="C=US, ST=Massachusetts, L=Boston, O=CompanyInc, CN=vpn"

ipsec.conf on "vpn":
version 2.0

config setup
    plutodebug="control controlmore"
    nat_traversal=yes
    virtual_private=%v4:
10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!10.0.0.0/24<http://10.0.0.0/8,%25v4:192.168.0.0/16,%25v4:172.16.0.0/12,%25v4:%2110.0.0.0/24>
    interfaces=%defaultroute

conn %default
    keyingtries=1
    compress=yes
    auto=add

conn openswan-part
    leftsubnet=10.0.0.0/24
    #### rightsourceip=192.168.2.1
    rightsubnet=vhost:%no,%priv
    left=%defaultroute
    right=%any
    authby=rsasig|secret
    leftcert=vpn.pem
    rightrsasigkey=%cert

After I bring the the connection up (from lithium), 'route -n' reports the
following new entries
On "lithium":
Destination     Gateway         Genmask         Flags Metric Ref    Use
Iface
10.0.0.0        192.168.2.1     255.255.255.0   UG    0      0        0 eth0
 On "vpn":
Destination     Gateway         Genmask         Flags Metric Ref    Use
Iface
192.168.2.2     66.92.44.161    255.255.255.255 UGH   0      0        0 eth1

And from "lithium", I can reach (ping/ssh/tracepath) "vpn" and other hosts
on the 10.0.0.0/24 network.  E.g.:
$ tracepath 10.0.0.1
 1?: [LOCALHOST]     pmtu 1448
 1:  lithium.localdomain (192.168.2.2)                      0.081ms pmtu
1418
 1:  10.0.0.1 (10.0.0.1)                                   34.536ms reached
     Resume: pmtu 1418 hops 1 back 1
 So far so good.  Obviously I'm also getting the return packets.

The problem:  Any traffic initiated by "vpn" toward 192.168.2.2 (lithium)
fails.  From tracepath I see the packets go out the "normal" route to the
public internet; I see two Speakeasy hosts (starting with 66.92.44.161),
then "No reply" for all further hops.

I tried changing ipsec.config on "vpn"(left), setting once "leftsourceip=
10.0.0.1" and the other time "rightsourceip=192.168.2.1".
I "ipsec auto --replace"d the connection.  It didn't make a difference.

Thank you again for all your help.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20061126/6e2b1468/attachment.html