Leaderboard

I finally found a solution, I re-installed the VPS with CentOS 6 (originally I deployed Debian 9) and I used the following rules: Now, I can access my server from the internet.

Hi, I decided this week wire my house and build a home network, As part of my home network, I purchased an old Xserve from 2009 and I installed macOS Sierra, But the problems start when I try to access the server outside of my network, I forwarded the ports on my Router but I found another problem, My router is inside a big NAT from my ISP. (I stole a diagram from ServerFault that shows my situation) So I thought in two possible solutions: Get a Dedicated IP from my ISP Use a VPN First of all, I called to my ISP asking for a dedicated IP address, unfortunately they only offer dedicated IP in business plans (that are kinda expensive), so it's not an option for me. So I decided to go with the second option, use a VPN. I purchased a small VPS with two dedicated IP address (x.x.x.x and y.y.y.y) from a very know cloud provider, and then I proceed to install xl2tpd with IPsec in the VPS. Installing XL2TPD with IPsec in CentOS 6 Searching on Google, I found very easy-to-use installation script, that you can find on GitHub here: https://github.com/hwdsl2/setup-ipsec-vpn It's very recommendable first of all update the OS dependencies execution "yum update", and then install IPsec. You can do all this in one step: yum -y update && wget https://git.io/vpnsetup-centos -O vpnsetup.sh && sudo sh vpnsetup.sh && chkconfig ipsec on And that's been all, You will see in the terminal at the end of the installation your VPN access details, Save this in a secure place. Enabling IP Forwarding After the installation I tested the VPN on my computer and my Android Phone, and the navigation works pretty well. So in order to get access to my server from the Internet, I configured the VPN on the server, You can find here a detailed explanation how to configure your new VPN in your OS: https://github.com/hwdsl2/setup-ipsec-vpn/blob/master/docs/clients.md Now when your server is connected to the VPN, we need to check what is the Local IP assigned by the VPN to our server, For explanation purposes I will use the IP z.z.z.z, The installation script by default adds a DROP policy to the Iptables firewall, so first we need to remove them. First we must activate the IP forwarding, to activate it you must modify the following parameters as shown below net.ipv4.ip_forward = 1 net.ipv6.conf.all.accept_ra=2 net.ipv6.conf.eth0.accept_ra=2 These parameters must be modified, or if they do not exist add them at the end, in the file /etc/sysctl.conf Now we will save all the Iptables rules in a file called "rules.v4" mkdir /etc/iptables/ iptables-save > /etc/iptables/rules.v4 Then open the new file with vi or nano. nano /etc/iptables/rules.v4 Now you need to find those lines in the file and remove them and save the file: -A FORWARD -j REJECT --reject-with icmp-host-prohibited -A INPUT -j REJECT --reject-with icmp-host-prohibited After save the file you need to restore them to Iptables, to update the new rules: iptables -F iptables-restore < /etc/iptables/rules.v4 service iptables save service iptables reload Now the final step, you need enable IP Forwarding at the OS level: echo "1" > /proc/sys/net/ipv4/ip_forward && sysctl net.ipv4.ip_forward=1 Now, reboot your VPS. Forward Local IP Now to access your server from the Internet, we need forward the Local IP (z.z.z.z) to the Public IP, I will forward the server to the y.y.y.y IP. This step is easy, we only need add some rules to Iptables, this rules will forward all the ports to the local IP. iptables -t nat -A POSTROUTING -o eth0 -s z.z.z.z -j SNAT --to-source y.y.y.y iptables -t nat -A PREROUTING -i eth0 -d y.y.y.y -j DNAT --to-destination z.z.z.z iptables -A FORWARD -s y.y.y.y -j ACCEPT iptables -A FORWARD -d z.z.z.z -j ACCEPT service iptables save service iptables reload And that is all! Now you can access your amazing server from http://y.y.y.y/

Yes, but as far as I know they aren't a payment gateway. They provide hosted wallets, and can be used for direct payments. Personally I suggest not using a hosted wallet, if they get hacked (mtgox anyone?) then you may lose all your coins.

We are planning a Payoneer gateway (I assume this is what you mean?). Also, for Bitcoin we recommend BitPay, which we have a gateway for.

Very nice! I love posts like this.

Thanks, CentOS it's much better than Debian IMHO. I will make a last update, When I connect my computer to the VPN I can't access the Server, I can access the server only from the Internet but not inside the VPN, So I added this additional rules: I hope this thread some day can help other people with a similar problem. iptables -t nat -A POSTROUTING -s z.z.z.z -j SNAT --to-source y.y.y.y iptables -t nat -A PREROUTING -d y.y.y.y -j DNAT --to-destination z.z.z.z iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Blesta isn't as nearly as ioncube encrypted as WHMCS is so you don't need module for google analytics and I would recommend you check out piwik instead(both have javascript trackers and can be easily integrated into your installed blesta's client view structure.pdt file.) I don't know what Blockchain v2 is unless it is related to bitcoin which in that case I suggest checking out coinbase as @Paul has suggested that to me for bitcoin payment processing. Gateway Fees which I assume basically add the paypal fee's you pay to the client's invoice as a tax is what I have heard before(which in paypal's own terms is against their terms of service) so will not help you with that. the payeer & perfect money module I don't think one is available yet but you could ask @Paul if he could add that as a feature request

I love how a script with automation would work. Set the times open and closed, and specify if you are closed on a holiday or partial hours.. maybe a lunch break.. and then the automation decides when to show your banner. I only have one suggestion.... Make it sticky to the top so that when scrolling down and looking at services, you are reminded if they're closed or not.

Here's a paste of the (relevant) exim logs that they provided for me (emails and IP addresses are all anonymised): https://paste.ee/p/GhRPr#f1J0xUE7zzgbmteWWwTDsmf7kt757I98 /var/log/exim_mainlog:2017-07-17 16:25:02 H=([127.0.0.1]) [Blesta_IP_Address]:36188 X=TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128 CV=no F=<billing@example.com> A=dovecot_login:smtp-username@domain.com rejected RCPT <recipientemail@domain.com>: Sender verify failed /var/log/exim_mainlog:2017-07-17 16:26:09 H=(my.example.com) [Blesta_IP_Address]:37270 X=TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128 CV=no F=<sales@example.com> A=dovecot_login:smtp-username@domain.com rejected RCPT <recipientemail@domain.com>: Sender verify failed /var/log/exim_mainlog:2017-07-17 16:26:40 H=(my.example.com) [Blesta_IP_Address]:37450 X=TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128 CV=no F=<sales@example.com> A=dovecot_login:smtp-username@domain.com rejected RCPT <recipientemail@domain.com>: Sender verify failed /var/log/exim_mainlog:2017-07-18 10:14:06 H=(my.example.com) [Blesta_IP_Address]:48182 X=TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128 CV=no F=<billing@example.com> A=dovecot_login:smtp-username@domain.com rejected RCPT <recipientemail@domain.com>: Sender verify failed /var/log/exim_mainlog:2017-07-18 10:16:08 H=(my.example.com) [Blesta_IP_Address]:49364 X=TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128 CV=no F=<billing@example.com> A=dovecot_login:smtp-username@domain.com rejected RCPT <recipientemail@domain.com>: Sender verify failed /var/log/exim_mainlog:2017-07-18 10:38:34 H=(my.example.com) [Blesta_IP_Address]:44890 F=<billing@example.com> A=dovecot_login:smtp-username@domain.com rejected RCPT <recipientemail@domain.com>: Sender verify failed /var/log/exim_mainlog:2017-07-18 10:43:03 H=(my.example.com) [Blesta_IP_Address]:48352 F=<billing@example.com> A=dovecot_login:smtp-username@domain.com rejected RCPT <recipientemail@domain.com>: Sender verify failed /var/log/exim_mainlog:2017-07-18 10:43:22 H=(my.example.com) [Blesta_IP_Address]:37954 X=TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128 CV=no F=<billing@example.com> A=dovecot_login:smtp-username@domain.com rejected RCPT <recipientemail@domain.com>: Sender verify failed /var/log/exim_mainlog:2017-07-18 10:44:07 H=(my.example.com) [Blesta_IP_Address]:38252 X=TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128 CV=no F=<billing@example.com> A=dovecot_login:smtp-username@domain.com rejected RCPT <recipientemail@domain.com>: Sender verify failed All of those "Sender Verify Failed" errors occur when sending from the root domain. On the other hand, on any subdomain, there is no such error: /var/log/exim_mainlog:2017-07-18 11:32:30 1dXVQE-00043Y-3g <= sales@my.example.com H=(my.example.com) [Blesta_IP_Address]:38178 P=esmtpsa X=TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128 CV=no A=dovecot_login:smtp-username@domain.com S=2027 id=cca1af60f07ba5bb530da86ad7c459c4@my.example.com T="Welcome to My Company" for recipientemail@domain.com / That is probably why the errors were occurring, the incoming mail server (at the same provider) was rejecting the mails from Blesta because it couldn't verify that my Blesta install actually sent them. EDIT: Yep, the above is the case. Their cPanel server requires the email address to be created in cPanel before you can send emails from it, otherwise, you'd end up with the sender verification errors.

I tried it with ElasticEmail (another hosted SMTP service) which I already had an account with. The email sends successfully for the root domain, a nonexistent subdomain, and the Blesta install URL. The same occurs with Sendgrid and Mailgun, so we can probably narrow it down to it being my mail provider's fault. I've asked them for a copy of their recent SMTP logs for my domain (I'll get back with what they say).