hi,
i try to make VPN IPSEC mikrotik-linux (centos 7).
I have mikrotik in my house and i want to make VPN with a virtual PBX in cloud.
For this i try to use openswan. I read some post in internet but my conf not work.
Can anyone help me or suggest a better solution for a VPN between mikrotik with a cloud server?
This my conf:
ipsec.conf
# basic configuration
config setup
nat_traversal=yes
oe=off
protostack=netkey
uniqueids=yes
fragicmp=no
# Add connections here
conn %default
type=tunnel
keyingtries=0
disablearrivalcheck=no
authby=secret
esp=3des-sha1
ike=3des-sha1;modp1024
keyexchange=ike
left=IPLOCALESERVERLINUX
pfs=no
conn Mikrotik
left=IPPUBBLICOSERVERLINUX
leftid=IPPUBBLICOSERVERLINUX
leftsourceip=IPLOCALESERVERLINUX
leftsubnet=RETELOCALESERVERLINUX
leftnexthop=%defaultroute
right=IPPUBBLICOMIKROTIK
rightid=IPPUBBLICOMIKROTIK
rightsubnet=RETELOCALEMIKROTIK
rightnexthop=%defaultroute
keyingtries=0
pfs=yes
aggrmode=no
#ike=3des-sha1;modp1024 ## Or what you want just so it matches the other router
esp=3des-sha1;modp1024
authby=secret
keyexchange=ike
#questo avvia la VPN appena il server si avvia
auto=start
ikelifetime=86400s
keylife=3600s
This mikrotik conf:
;;; VPN CLOUD
src-address=RETELOCALEMIKROTIK src-port=any dst-address=RETELOCALESERVERLINUX
dst-port=any protocol=all action=encrypt level=unique
ipsec-protocols=esp tunnel=yes sa-src-address=IPPUBBLICOMIKROTIK
sa-dst-address=IPPUBBLICOSERVERLINUX proposal=default ph2-count=0
ip ipsec proposal print
Flags: X - disabled, * - default
0 * name="default" auth-algorithms=sha1 enc-algorithms=3des lifetime=30m
pfs-group=none
I wonder what was it what you’ve read in the internet, given that the part of Mikrotik side configuration you’ve posted contains about 1/4 of the necessary settings.
Have you tried the Mikrotik documentation on IPsec? It explains the basics quite nicely (what is Phase 1, what is Phase 2, what are they good for, where to configure their parameters) and provides examples for various use cases.
I am using strongswan (rather than openswan) against Mikrotik on the opposite end on multiple places, but the syntax of ipsec.conf is the same on both so unless you try something really advanced, openswan should do.
In any case, disappointment is guaranteed if you try to set up IPsec without at least a rough understanding of its concept and principles.
As for other VPNs, yes, there are other possibilities, but as you’ve mentioned VoIP as a purpose, I’m afraid none of them is useful for your case. Any VPN is simpler to configure than IPsec, but those which are secure enough (SSTP, OpenVPN) are not really useful for real time data like RTP because they use TCP to transport the encrypted data (this is not true for OpenVPN any more if you use RouterOS v7 beta, but it’s a beta and may not be available for your model) and by experience SSTP is quite slow (which may be a matter of implementation but so it is for now). L2TP without IPsec provides no security, and PPTP’s own security cannot be considered secure since many years ago.
hi,
tanks sindy for your response.
I have make some other VPN IPsec site to site with mikrotik on all side and all work ok.
in the previous post I skipped some configurations that I thought were “automatic”. I apologize for this
I had already read the document that signaled me, however this time I followed it in detail trying to configure strongswan on debian with mikrotik.
But the VPN not work. I have on linux debian:
no IDi configured, fall back on IP address
no private key found for ‘PUBLICIPDEBIAN’
establishing connection ‘ikev2’ failed
You can use pem format too, but then you get two files - the certificate itself and its private key end up in separate files, and you have to import both at the remote peer, plus the CA one separately. With pkcs12 format, the complete chain of trust from the root CA down to the client certificate itself and its private key is stored in a single file.
If you use the proper way of certificate generation, where a request is generated at the client and sent to the CA which signs it, the private key is created at the client, so there is no need to transfer it from one equipment to another. Unfortunately, there is currently a RouterOS limitation when using this proper way - it cannot sign certificate requests with ECDSA ciphers.