. (I pay - I decide!) The same way an admin could make all ports open to the outside (or whatever), you wouldn't prevent that, would you? If I would have known this, I would have bought a Juniper or Vigor.Feature request: Aggressive mode IPSEC with pre-shared key
I would be greatly thankful for the aggressive mode option in the pre-shared key ipsec vpn tunnels. It is a very little risk whilst the peer ID of the initiator is sent in clear. IKE aggressive mode hacking is possible only as a brute force with weak keys, even then it's not very easy. In many cases there is a need for quickly establishing an ipsec vpn tunnel from a site with a dynamic IP without using the certificates therefore strong keys, the rekey protection, ect. must be used. All the big (and even small) manufacturers (Juniper, Cisco, ect.) allow the user chose whether to use certificates or a pre-shared key in the aggressive mode key exchange. I am totally disappointed that the MT staff don't let the end-user itself to decide what is safe and what is not . (I pay - I decide!) The same way an admin could make all ports open to the outside (or whatever), you wouldn't prevent that, would you? If I would have known this, I would have bought a Juniper or Vigor.
. (I pay - I decide!) The same way an admin could make all ports open to the outside (or whatever), you wouldn't prevent that, would you? If I would have known this, I would have bought a Juniper or Vigor.Re: Feature request: Aggressive mode IPSEC with pre-shared k
Same here.
Can't understand why this feature isn't available. Every ipsec capable router supports aggressive mode with peer id's. But Routeros doesn't. This is a total fail and lack of basic functions. This can't be a security reason because using the same psk and policy generation for all road warriors is much more insecure. Even with rsa keys it's insecure when you have to use policy generation.
I guess mikrotik doesn't understand ipsec, that's the real reason.
My RB750 is going to the trash now, no need for wasting time
Can't understand why this feature isn't available. Every ipsec capable router supports aggressive mode with peer id's. But Routeros doesn't. This is a total fail and lack of basic functions. This can't be a security reason because using the same psk and policy generation for all road warriors is much more insecure. Even with rsa keys it's insecure when you have to use policy generation.
I guess mikrotik doesn't understand ipsec, that's the real reason.
My RB750 is going to the trash now, no need for wasting time
Re: Feature request: Aggressive mode IPSEC with pre-shared k
You do not have the required permissions to view the files attached to this post.
Re: Feature request: Aggressive mode IPSEC with pre-shared k
Did you understand the feature request? Aparently not.
The need is for specifying the REMOTE ID for Phase-1 peer identification as used by any other IPSec-capable routers. That one can set a local FQDN is not enough.
The need is for specifying the REMOTE ID for Phase-1 peer identification as used by any other IPSec-capable routers. That one can set a local FQDN is not enough.
Re: Feature request: Aggressive mode IPSEC with pre-shared key
Hi!
That feature request is quite old, but still unsolved. Will there be any possibility to work with IPSEC on dynamic IPs without the need of any "DYNDNS-hacks" or a second L2TP-Layer?
The need to use IPSEC in combination to L2TP leads to an additional layer of complexity. Other vendors allow to configure IPSEC in a way that one peer does not need to know his own IP and/or the ip of the other peer. E.g. StrongSWAN and many other firewalls have the possibility, that one of the peers can be behind a NAT without the need of any DYNDNS-hacks.
Authentication should be possible with "ID" "PSK" without IP for Phase 1 and Phase 2.
Are there any plans?
Regards,
Stril
That feature request is quite old, but still unsolved. Will there be any possibility to work with IPSEC on dynamic IPs without the need of any "DYNDNS-hacks" or a second L2TP-Layer?
The need to use IPSEC in combination to L2TP leads to an additional layer of complexity. Other vendors allow to configure IPSEC in a way that one peer does not need to know his own IP and/or the ip of the other peer. E.g. StrongSWAN and many other firewalls have the possibility, that one of the peers can be behind a NAT without the need of any DYNDNS-hacks.
Authentication should be possible with "ID" "PSK" without IP for Phase 1 and Phase 2.
Are there any plans?
Regards,
Stril