Open glennschler opened 2 years ago
Currently testing fix glennschler@8865b1ab06c1c75d8e3754c56595f37ecfa87f9d
Although unused IPSec and WireGuard ports are opened on cloud provider firewalls, unused ports are not opened on the server instance itself.
Yes, I understood and it is explained well in the algo firewall document. iptables -L
confirms as well. The ports referred to in this issue are the external "security group" firewall which EC2 provides to control access in/out of the VPC.
It's a minor detail. The fix creates a more explicit cloud formation template. I always found myself deleting these rules manually after deployment of algo to avoid future confusion.
Describe the bug When deploying to ec2-cloud, and the
ipsec_enabled
parameter isfalse
a new EC2 external firewall Security Group is created with two unnecessary ingress firewalls rules. The two inbound ipsec ports are 500 and 4500. Since the ipsec strongswan role is exlcuded, there is no strongswan VPN deployed on the new hosted instance, so no need for these open ports.To Reproduce
Steps to reproduce the behavior:
ipsec_enabled
parameter tofalse
After Algo completes the deployment, note the public IPv4 shown in the final lines of "PLAY RECAP"
describe-security-groups
anddescribe-instances
cli command using the public IP to see the ingress rules which were created:Another way to view the rules is in the AWS Dashboard->AWS Services ->CloudFormation->Stacks page. Examine the Stack Details->Resources to find the InstanceSecurityGroup which was created. Open the Physical ID of the SG to view the Inbound Rules
Expected behavior
When
ipsec_enabled = false
, there should only be two security group rules. One for SSH and one for Wireguard.Additional context
Perhaps consider the case when
wireguard_enabled = false
as well. Do not open that port when not enabled.