[Openswan Users] Routing Problem

[Paul Wouters]

On Thu, 10 Nov 2005, Stefan Keller wrote:

> 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

Our handling of rp_filter changed. Perhaps we should be more aggressive.
Note there is a difference between disabling rp_filter for "all", "default"
or a specific (active) network interface. If using /etc/sysctl.conf, disable
the "all" version of the rp_filter setting.

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

If you are using NETKEY, you might need to disable some bogus Linux icmp
redirects. Similarly to rp_filter, change the send_redirects option at
 /proc/sys/net/ipv4/conf/all/send_redirects

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

Yes, it defaults to the IP address, so if you have multiple connections that
are similar and use the same IP address oon the VPN gateway, it might not
unique identify between two of those connections.

for example:

conn paul
	left=%defaultroute
	right=%any
	leftrsasigkey=0s-serverkey
	rightrsasigkey=0s-paulskey

conn ken
	left=%defaultroute
	right=%any
	leftrsasigkey=0s-serverkey
	rightrsasigkey=0s-kenskey

Now there is an incoming connection. Is it paul or ken? openswan cannot tell
the difference in time (even though there are different RSA keys associated
with right. The fix is:

conn paul
	left=%defaultroute
	leftid=@server
	right=%any
	rightid=@paul
	leftrsasigkey=0s-serverkey
	rightrsasigkey=0s-paulskey

conn ken
	left=%defaultroute
	leftid=@server
	right=%any
	rightid=@ken
	leftrsasigkey=0s-serverkey
	rightrsasigkey=0s-kenskey

Since the incoming rightid= is sent at the start of the IKE negotiation, it
will help us differentiate these two conenctions in time now.

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

The problem is you cannot be 192.168.0.x and have a subnet=192.168.0.0/24.
The easiest setup for two servers in the same lan is just using a direct
host-host ipsec connection without using a gateway. Use another connection
for protecting 0.0.0.0/0. Openswan will pick the most specific IPsec SA,
so this should work. (Not entirely sure if this would work on NETKEY, now I
think of it, I think it should though)

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

The problem you are introducing with this is assymetric routing. Let's assume
the firewall and vpnserver are different, and the vpnserver is not the default
gateway for the inside client (but firewall is):
                   ---vpnserver-------+
                  /                   |
roadwarrior------+---firewal------insideclient

So the packet flow will now be (when IPsec is up)
1) roadwarrior sends encrypted packet for inside client to VPNserver
2) vpnserver decrypts and sends plaintext packet to inside client
3) inside client answers and sends plaintext packet for roadwarrior on
   dynamic IP, which it knows nothing about, to default gateway(firewall)
4) default gateway/firewall sends plaintext packet to roadwarrior
5) roadwarrior expected a crypted packet and drops it.

If you had a setup like:

roadwarrior----firewall--vpnserver----inside client, or:
roadwarrior-----vpnserver----firewall----inside client

then this problem does not happen, because at some point the vpnserver
sees the packets, knows it has an IPsec poolicy, and encrypts the packet.

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

Yes, if you NAT the packet on the vpnserver, then you 'force' the inside
client to think it is talking to the VPN server itself, and it will receive
the packets back and be able to de-NAT and forward to the roadwarrior. But
this will break for various protocols that won't work well through NAT, eg
forget trying to mount a network drive from inside client to roadwarrior.

Another solution is to use L2TP (or ModeConfig) and assign an internal IP
to the roadwarrior, so the roadwarrior now appears to be inside the internal
network.

Paul