Question:
How can I set up a router inside my cloud?
Environment
OnApp 5.x
Solution
Starting from OnApp version 5.3, this functionality is included in the feature called Virtual Server as a Gateway
For other versions, here is a workaround:
If you are going to add these rules, they need to be in place at least on the HV where the router will be hosted, but it is recommended that you have them on all HVs.
The rule should look like this:
iptables -A FORWARD -s <ip_vm> -j ACCEPT
where <ip_vm> - ip address of the VM (or VMs' network) that is getting to the internet via the router in the cloud.
You should also be aware that the iptables service is turned off on the HVs. If you need these rules enabled after rebooting, you would need to add them to the end of /etc/rc.local.
Additional Information
The reason a rule like this is necessary for this situation is because of how IP routing works in the OnApp environment.
Each VM's network interface is its own chain in the firewall. In this chain you can add rules using the CP from the GUI. However, only IP packets with the destination address of the VM can be put into the VM's chain. The default policy of FORWARD is DROP. So if the IP packet isn't put into a VM's chain, it is automatically dropped.
Comments
3 comments
It would be nice if this could be allowed via API or via CP.
Whole problem is due to the firewall rules OnApp generates for a VM containing an "anti-spoofing" guard. That is - no packet can leave/reach a virtual interface if it's not sourced/destined to one of the IPs assigned to that interface. That is of course smart and necessary feature in a cloud environment. It does however block any router-like functionality (NAT router for private-only machines, VPN gateway etc).
The above workaround, if I understand it correctly, at least partly bypasses firewall rules defined for VMs. We don't see this as a desired behavior - it makes any troubleshooting complicated and effective rules being applied hardly understandable. We have developed and use at our clouds for quite long now a much better solution:
The attached script takes as a single parameter a name of the virtual interface that needs to have the anti-spoofing guard disabled.
When executed incorrectly or the specified virtual interface does not exist it exits with the error message printed to stderr.
If the specified interface exists and does have an anti-spoofing guard - the guard is disabled and all: the "iptables -R" command executed, the rule before and after the change are logged to /var/log/messages.
If the specified interface exists but it already has the guard disabled - the script is NOP.
We ourselves run the script from cron every 5 minutes for all router-like private-side interfaces. The script does not interfere with the firewall rules for VMs, it only disables the guard. Of course due to anti-spoofing disabled the VMs become a better target for malicious attack. Consider the script public domain.
I don't see an attached script, Aleksander.
Do you have an external link to the script?
Please sign in to leave a comment.