TKS for your patch,I test it without the next-server configuration in dhcpd,and It make the client get the right virtual IP address. not the ip relation with virtual ip address is below:DHCP Server:10.1.0.111Server:10.1.0.1(192.168.0.7)Client:10.1.0.122(192.168.0.15) when I ping from client to server:ping 10.1.0.1 -I 10.1.0.122, ping can reach the server, but when I ping from client to DHCP Server:ping 10.1.0.111 -I 10.1.0.122 I found the ping packet on eth0(bind to IP 192.168.0.7 which connect to client)but no ping packet on eth1(bind to IP 10.1.0.1 which connect to DHCP Server) DO I NEED TO CONFIG THE ROUTE TABLE MANUALLY below is the ipsec statusall's result, debianleft:~# ipsec statusall host-hostStatus of IKEv2 charon daemon (strongSwan 4.4.0): uptime: 11 minutes, since Oct 18 23:12:07 2010 worker threads: 7 idle of 16, job queue load: 0, scheduled events: 2 loaded plugins: curl aes des sha1 sha2 md5 random x509 pubkey pkcs1 pgp dnskey pem openssl fips-prf xcbc hmac gmp attr kernel-netlink socket-raw farp stroke updown dhcp resolveListening IP addresses: 192.168.0.7 10.1.0.1Connections: host-host: 192.168.0.7...%any host-host: local: [[email protected]] uses public key authentication host-host: cert: " xxxxx" host-host: remote: [%any] uses any authentication host-host: child: 10.1.0.0/24 === dynamicSecurity Associations: host-host[1]: ESTABLISHED 11 minutes ago, 192.168.0.7[[email protected]]...192.168.0.15[[email protected]] host-host[1]: IKE SPIs: 5593331acc599847_i 4d93fa753cf9969f_r*, public key reauthentication in 45 minutes host-host[1]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048 host-host{1}: INSTALLED, TUNNEL, ESP in UDP SPIs: c03a569c_i cf1a06d0_o host-host{1}: AES_CBC_128/HMAC_SHA1_96, 53928 bytes_i (226s ago), 35196 bytes_o (226s ago), rekeying in 2 minutes host-host{1}: 10.1.0.0/24 === 10.1.0.122/32
> Subject: RE: [strongSwan] why my can not get the ip from dhcp server > From: [email protected] > To: [email protected] > CC: [email protected] > Date: Mon, 18 Oct 2010 12:36:06 +0200 > > > > but why we must need this parameters, it is the next server ip > > address. > > Yes, we probably should prefer the 'server identifier' attribute instead > of the 'siaddr' to send the REQUEST to. > > Please try the attached patch. It is completely untested, though. > > Regards > Martin
_______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
