[Openswan Users] Routing Problem

[Stefan Keller]

Paul, thank you very much for your answer. I am sorry about this 
example.com stuff, it is just an ordinary private network, I thought it 
helps clarifying the situation.

About rp_filter and ip_forward: these values were not set to 0 and 1, 
respectively, so I added this. (By the way, the option "rp_filter=0" in 
the config setup section does not seem to have any influence, actually, 
this should even be the default.) Now, on the vpnclient side, I get a 
notification, that the ping to another destination gets a redirection at 
the vpngateway. But there is no further routing.

About the missing "rightid=" on the vpngateway ipsec.conf: Isn't there a 
default to "right"? Otherwise, what has to be set there, since there 
might be several clients with valid keys, which are allowed to connect 
to the vpngateway?

The network is very ordinary and looks like this (the domain is called 
"office.risksys.ch"):

Network: 192.168.0.0/24
Default Gateway and firewall: 192.168.0.1
DNS and several other machines are around
amber: 192.168.0.34
duvel: 192.168.0.37

The latter ones, amber and duvel, are ordinary desktops. The idea is to 
get a VPN connection from duvel, being the vpnclient, to amber, being 
the vpngateway and further to the whole network. I added the real 
ipsec.conf below. Without starting ipsec, both hosts would be ordinary 
clients in the network.

You mention the VPN gateway should always be the default gateway - 
therefore, it has to be identical with the firewall on 192.168.0.1. And 
furtheron, I assume, the VPN client should not be in the same subnet - 
in my situation, it should not be in 192.168.0.0/24, is this right?

And thinking about the setup I want to introduce finally, where "real" 
roadwarriors from anywhere can connect to the internal network. The VPN 
gateway has to be identical with the firewall? Isn't there a possibility 
to have, e.g. a separate host with an own public address and a 
connection to the internal network (having, e.g. an internal ip address 
of 192.168.0.111), parallel to the firewall, which deals with all the 
VPN connections? In this situation, from the point of view of the 
internal network, it would not be the default gateway.

Or, another thinkable setup, the VPN gateway is completely internal, 
where all the incoming VPN traffic is NATed and forwarded at the 
firewall to, lets say, 192.168.0.112. Again, this host would not be the 
default router for the internal network.

Indeed, all the routing stuff seems to be the difficult part!


Have a good day

Stefan




The ipsec.conf on amber, the vpngateway, looks like this:

config setup
        interfaces=%defaultroute
        nat_traversal=no
        plutodebug=all
        forwardcontrol=yes
        rp_filter=0 # does not seem to work

conn %default
        leftcert=%cert
        rightcert=%cert
        authby=rsasig

conn roadwarrior
        left=192.168.0.34
        leftid=@amber.office.risksys.ch
        leftsubnet=0.0.0.0/0
        leftcert=amber.office.risksys.ch_cert.pem
        right=%any
        auto=add


and on duvel, the vpnclient

config setup
        interfaces="ipsec0=eth0"
        nat_traversal=no
        plutodebug=all
        forwardcontrol=yes
        rp_filter=0

conn %default
        authby=rsasig

conn roadwarrior
        left=192.168.0.37
        leftid=@duvel.office.risksys.ch
        leftcert=duvel.office.risksys.ch_cert.pem
        right=192.168.0.34
        rightid=@amber.office.risksys.ch
        rightsubnet=0.0.0.0/0
        rightcert=amber.office.risksys.ch_cert.pem
        auto=add


Paul Wouters schrieb:

>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
>  
>