>Stig wrote: >I think the reason for the immediate re-establishment is the "auto=start" >value in /etc/ipsec.conf. If you want to experiment you could try logging >in as root and edit /etc/ipsec.conf and change "auto=start" to "auto=add". >Then go back into xorpsh and do a "clear vpn ipsec-process" to reread the conf file. If that works then I can send you a patch to the perl script >that generates that conf file.
Hi Stig, Yes, you are correct. Modifying that value does the trick. It's logical actually. After Vyatta boots, it tries automatically to bring up the tunnel. That's not bad, but it would be nice if we could specify that from the cli. If the tunnel is not needed, why it should be up when the machine starts? However, after I run the "clear vpn ipsec-process" command, I was unable to start the tunnel from a client behind Vyatta(simply using ping). Trying with a client from behind ISA and the tunnel was up. Actually the ICMP request message was sent in clear by Vyatta to the client behind ISA instead of starting IKE negotiations. But once the tunnel was up and ISA deletes the IPsec SA due to its idle timer, Vyatta too deletes the IPsec SA and does not automatically start the QM. I can start without any problems the QM negotiations from a host behind Vyatta now, complete them and then pass traffic. In fact, if I reboot ISA(to clear any SAs), I can bring up the tunnel from a host behind Vyatta without any issues(the problem after the "clear vpn ipsec-process" command dissapears). By the way, do you guys plan to add support for certificate authentication for IKE(configure on Vyatta a trusted CA, specify a certificate obtained from this CA, do CRL checking...) ? Thanks, Adrian _______________________________________________ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
