[Openswan Users] Routing Problem

[Paul Wouters]

On Wed, 9 Nov 2005, Stefan Keller wrote:

> conn %default
>        leftcert=%cert
>        rightcert=%cert
>        authby=rsasig
>
> conn roadwarrior
>        left=192.168.0.34
>        leftid=@vpngateawy.example.com
>        leftsubnet=0.0.0.0/0
>        leftcert=vpngateawy.example.com_cert.pem
>        right=%any
>        auto=add

note there is no rightid= here.

> ipsec.conf on vpnclient (192.168.0.37):
>
> version 2.0
> config setup
>        interfaces="ipsec0=eth0"
>        nat_traversal=no
>        plutodebug=all
>
> conn %default
>        authby=rsasig
>
> conn roadwarrior
>        left=192.168.0.37
>        leftid=@vpnclient.example.com
>        leftcert=vpnclient.example.com_cert.pem
>        right=192.168.0.34
>        rightid=@vpngateway.example.com
>        rightsubnet=0.0.0.0/0
>        rightcert=vpngateway.example.com_cert.pem
>        auto=add

but here there is a leftid and rightid.

> The result looks good, there is an "IPsec SA established" on both sides.

It shouldn't :)

> data can be exchanged, e.g. a ping or ssh from the vpnclient to the vpngateway
> and vice versa is working, while the tcpdump shows all this ESP connections
> and only them.
>
> But any other destination behind the vpngateway can not be reached. For
> example, lets run a ping on the vpnclient to any valid destination, lets take
> 192.168.0.3 in the private network, which can be resolved to
> anydestination.example.com. tcpdump on vpnclient gives:
>
> 14:50:05.020033 IP 192.168.0.37 > 192.168.0.34: ESP(spi=0x75c766d8,seq=0xd43)
>
> tcpdump on vpngateway gives:
>
> 14:50:05.231591 IP vpnclient.example.com > vpngateway.example.com:
> ESP(spi=0x75c766d8,seq=0xdc6)
> 14:50:05.231591 IP vpnclient.example.com > anydestination.example.com: icmp
> 64: echo request seq 1
>
> As can be seen, the vpngateway gets the ESP data and passes the request
> further to the host anydestination - but the request leaves the vpngateway in
> the name of the vpnclient. The host anydestination on the other hand does not
> see anything from this request, at least not with tcpdump, and does not give
> any answer. Therefore, vpngateway does not get an answer, neither vpnclient
> does.

You anonimized the IP's so I cannot tell if your network design works.
Remember that in this kind of setup, the VPN gateway should also be the
default gateway, orreturn packets will not go through the VPN gateway, and
will not get encrypted, and will get dropped by the client who is expecting
crypted packets.
Other issues might be ip forwarding being disabled, rp_filter being enabled,
NAT/MASQ rules, or 2.6 (bogus) send_redirects being enabled.

Paul