According to ipsec.conf manual:
pfs
whether Perfect Forward Secrecy of keys is desired on the connection's keying
channel (with PFS, penetration of the key-exchange protocol does not compromise
keys negotiated earlier); Since there is no reason to ever refuse PFS, Openswan
will allow a connection defined with pfs=no to use PFS anyway. Acceptable values
are yes (the default) and no.
Found removing the option would make it impossible to work with no PFS setting
router. It may related to CS-15511.
[Dropped Vmware support in this commit, due to lack of VMware support in VPC now]
Conflicts:
plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
We need to use ifup/ifdown to bring up the interfaces, because ifconfig don't
know the ip of the interface after we modify cloud-early-config to avoid
first start up of public interface.
Reviewed-by: Edison
In order to make sure next time, booting process would use cloud-early-config's
setup, rather than networking scripts to bring up interfaces.
Reviewed-by: Kelven Yang
I can't see why we set eth0 to dhcp by default. It would result in eth0 want to
get a DHCP address from outside. We should always assign ip through
cloud-early-config for it.
But one point is, the priority of cloud-early-config and networking script is
the same. So even networking got some ip from outside, cloud-early-config
should able to override it(if cloud-early-config runs after networking) or
networking script won't get dhcp (if cloud-early-config runs before networking),
so I am not quite understand why router would get DHCP address in fact. Maybe
there are other issues.
The routing table with two nics may be messed up, due to we sent same
router(gateway) information from different DHCP server, in order to specify
default gateway. E.g.
Network A: 192.168.1.0/24, gw 192.168.1.1
Network B: 192.168.2.0/24, gw 192.168.2.1
User VM: Nic 1 connect to network A, get ip 192.168.1.10; nic 2 connect to
network B, get ip 192.168.2.10.
Set network A as the default network of user VM.
Currently we would send this information to user VM through DHCP offer:
In network A: dhcp-option:router 192.168.1.1
In network B: dhcp-option:router 192.168.1.1
So both NIC in the guest VM would receive 192.168.1.1 as router(gateway).
But, in CentOS 5.6, dhclient-scripts try to tell if the gateway is reachable
for current subnet.
So when we try to enable nic 2(eth1) of user VM, dhclient would receive:
IP: 192.168.2.10
Mask: 255.255.255.0
Router: 192.168.1.1
Then it would found that the specified gateway(router) is not within its own
subnet(192.168.2.0/24). But since we send out this ip(192.168.1.1) as the
gateway for it, dhclient thought that it should got someway to access the
network through this IP. So it would execute:
ip route add 192.168.1.1 dev eth1
ip route replace default via 192.168.1.1 dev eth1
But it can never reach 192.168.1.1(which is in the eth0's subnet and the
gateway of eth0) by go through eth1 interface. So it is messed up.
We've tested Windows 2008 R2, CentOS 5.3, CentOS 5.6 and Ubuntu 10.04. Windows
and Ubuntu are fine with above policy.
To solve this, we send different dhcp:router option according to the guest OS
type now.
We may need expand this list later, but for now we only know that CentOS and
RHEL would behavior in this way.
status 14042: resolved fixed
