Issue Accessing NethSecurity Web UI and SSH After Restart – AWS EC2 Setup

[Milan_Johnson]

Hello,

I’m setting up a NethSecurity VPN server on an AWS EC2 instance and running into issues with firewall behavior after reboot. I’m still learning networking and could use some help understanding what’s happening, and how to configure this securely.
Setup Summary:
NethServer Security: nethsecurity-8-24.10.0-ns.1.5.1
NethSecurity is running on an EC2 instance
The server has two NICs:
WAN (with Elastic IP/public IP assigned)
LAN

VPN is configured to connect(VPN ip) via the WAN interface

The Issue:

On initial deployment, everything works fine:
I can access the Web UI via the WAN public IP
VPN connection works

However, after a reboot, and without a firewall rule allowing SSH (port 22) from the WAN interface:

1. I cannot access the Web UI via WAN public IP
2. I cannot SSH, even from the same subnet (via private IP)
3. VPN connection fails

Recovery Steps:

To regain access after reboot:

I attach an Elastic IP to the LAN NIC
I can then access the Web UI via LAN’s public IP
From the Web UI, I manually add a firewall rule to allow SSH (port 22) from any source on the WAN interface

This restores:
Web UI access via WAN
SSH from anywhere via WAN
PN connection via WAN

Additionally:
If I update the VPN server configuration to use the LAN’s public IP as the VPN gateway, VPN connections work again for existing users(also i have to change VPN’s ip as LAN’s ip ).

Clarifications:
The SSH allow rule on WAN is something I add manually from the UI.
The issue starts only after reboot — initial boot works fine even without SSH allowed on WAN.
The fact that I can’t even access via private IP from same subnet is confusing.

My Questions:
What’s the secure and proper way to:
Ensure VPN and Web UI access via WAN
Keep SSH access locked down?

Configuration of firewall with ssh allowed from WAN:

config defaults 'ns_defaults'
        option syn_flood '1'
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'

config include 'ns_user_include'
        option path '/etc/firewall.user'
        option fw4_compatible '1'

config include 'ns_hs_include'
        option type 'script'
        option path '/opt/icaro/dedalo/dedalo.user'
        option fw4_compatible '1'

config zone 'ns_lan'
        option name 'lan'
        list network 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'

config zone 'ns_wan'
        option name 'wan'
        list network 'wan'
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option masq '1'
        option mtu_fix '1'

config zone 'ns_e2c5f479'
        option name 'rwopenvpn'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'REJECT'
        list ns_tag 'automated'
        option ns_link 'openvpn/ns_roadwarrior_noremove'
        list device 'tunrw1'

config forwarding 'ns_lan2wan'
        option src 'lan'
        option dest 'wan'

config forwarding 'ns_fe43a03d'
        option src 'rwopenvpn'
        option dest 'lan'
        list ns_tag 'automated'
        option ns_link 'openvpn/ns_roadwarrior_noremove'

config forwarding 'ns_b38765cf'
        option src 'lan'
        option dest 'rwopenvpn'
        list ns_tag 'automated'
        option ns_link 'openvpn/ns_roadwarrior_noremove'

config forwarding 'ns_f615ac5a'
        option src 'rwopenvpn'
        option dest 'wan'
        list ns_tag 'automated'
        option ns_link 'openvpn/ns_roadwarrior_noremove'

config rule 'ns_allow_https'
        option name 'Allow-HTTPS-from-WAN'
        option proto 'tcp'
        option src 'wan'
        option dest_port '443'
        option target 'ACCEPT'

config rule 'ns_allow_ui'
        option name 'Allow-UI-from-WAN'
        option proto 'tcp'
        option src 'wan'
        option dest_port '9090'
        option target 'ACCEPT'

config rule 'ns_dhcp_wan'
        option name 'Allow-DHCP-Renew'
        option src 'wan'
        option proto 'udp'
        option dest_port '68'
        option target 'ACCEPT'
        option family 'ipv4'

config rule 'ns_ping_wan'
        option name 'Allow-Ping'
        option src 'wan'
        option proto 'icmp'
        option icmp_type 'echo-request'
        option family 'ipv4'
        option target 'ACCEPT'

config rule 'ns_7776fb80'
        option name 'Allow-SSH-from-WAN'
        option src 'wan'
        option target 'ACCEPT'
        option ns_service 'ssh'
        list proto 'tcp'
        list proto 'udp'
        option dest_port '22'
        option enabled '1'
        option log '0'

config rule 'ns_allow_OpenVPNRW1'
        option name 'Allow-OpenVPNRW1'
        option ns_service 'custom'
        option src 'wan'
        option dest_port '1194'
        list proto 'tcp'
        list proto 'udp'
        option target 'ACCEPT'
        option enabled '1'
        list ns_tag 'automated'
        option ns_link 'openvpn/ns_roadwarrior1'

NB: I’m fully aware that this is not a secure or recommended way to run a VPN server — especially exposing SSH to the public WAN. My goal is to understand what I’m missing and how to properly secure this setup while maintaining necessary access.

Would really appreciate any insights or best practices.

Thanks in advance!

[mrmarkuz (Markus Neuberger)]

Hi @Milan_Johnson ,

welcome to NethServer Community.

As regards SSH, it seems an AWS issue as there are a lot of search results about “aws ec2 no ssh after reboot”:

aws ec2 no ssh after reboot at DuckDuckGo

[Milan_Johnson]

Hi @mrmarkuz

Thanks for the warm welcome and your response.

I want to clarify that my main concern isn’t with SSH itself — I fully understand that without a firewall rule allowing port 22 from WAN, SSH access should be blocked. That’s expected.

---

The actual issue I’m facing is:

• If I don’t have an SSH (port 22) allow rule on WAN and then restart the EC2 instance, I lose access to the Web UI via the WAN public IP.
• If I then add a rule to allow SSH from WAN, both SSH and the Web UI start working again.
• The Web UI is running on port 443, and there’s no explicit rule blocking it — but access is only restored after the SSH rule is added.

Importantly, this does not happen immediately when I remove the SSH rule — Web UI access breaks only after a reboot when no SSH rule is present.

---

My question is:

• Why would Web UI access depend on an SSH rule, especially after a reboot?
• Is this a case of a firewall zone misconfiguration, or an AWS networking behavior I’m overlooking?

Thanks again for the support — I’m trying to understand what’s actually causing this behavior so I can secure the system properly.

[Tbaile (Tommaso Bailetti)]

Hi and welcome!

This is indeed a weird behaviour, will try my best to wrap my head around the issue, but I’m not excluding an issue in the VPS (due to tighten security, some providers have security in place that cuts out devices). I had issues while setting some configs on a Digitalocean instance, so your mileage may vary. However if the port 22 is not reachable through WAN, it shouldn’t trigger any security-related locks network wise.

Just a question, are you able to reach port https://:9090? This is where UI is reachable by default through WAN, might help pinpoint the issue.

Another question, do you have access to the instance through the AWS UI? A shell is enough. After you trigger the issue, try to access the machine directly through AWS (removing the need for SSH access, jumping directly to the shell of the machine) an try to poke around with pings from and to the LAN and WANs, if some pings are not successful, we are in a situation where probably the network has been cut off by some monitoring tool inside the AWS infra.

Please feel free to ask anything else if you need!

[Milan_Johnson]

Hi,

Thanks so much for the reply!

• Yes, I’ve been accessing the Web UI on port 443 and 9090 (which works initially), but I just tested https://<WAN-IP>:9090 and it does not respond after a reboot unless the SSH rule is enabled — same behavior as with port 443.
• I’ve tried connecting to the instance using EC2 Instance Connect after the issue occurs, but the attempt always fails, regardless of whether the instance is otherwise reachable (via SSH or Web UI).
• I can consistently SSH into the server using whichever public IP currently works for Web UI access. My current workaround, as mentioned earlier, is to attach Elastic IPs to both the LAN and WAN interfaces, and test each one. Usually, after changing a firewall rule for port 22 and rebooting:
  • The Web UI and SSH become inaccessible on the IP that was previously working.
  • The other Elastic IP (bound to the other NIC) suddenly starts working — almost as if the NICs are switching roles.I’m not sure if this kind of “IP/NIC switching” is possible, but I’ve even tried using MAC address binding to lock interface assignments — it didn’t solve the issue.
• Just to confirm again: this only happens after a reboot, and Web UI access returns immediately when I re-add the SSH allow rule on WAN, even though that rule is only for port 22. It seems like that rule is somehow unlocking more than just SSH.

---

One more strange thing I observed:

A few days ago, I changed the order of the firewall rules — the VPN rule became second-to-last, and the SSH rule became the last one. Immediately after that, the accessible public IP switched — the IP that was working became unreachable, and the other one started working instead.

The only change was the order of the rules, but it appeared to cause a swap in which IP was active externally. This is very confusing behavior and after

Steps I Followed

1. Initial Launch

• I start an instance with a single NIC.
• At this point, both SSH and the Web UI are accessible via the automatically assigned public IP on the primary NIC (LAN).

2. Attaching a Second NIC

• When I attach a second NIC (assumed WAN) without restarting the instance:
  • The original public IP on the primary NIC (LAN) becomes inaccessible.
  • SSH and Web UI are now only accessible via the Elastic IP attached to the second NIC (WAN).

3. Reboot Scenario

• If I restart the instance while both NICs are attached:
  • Even though I accessed server using WAN’s Public IP before restart, I can’t access it through it after restart and I have to access through the LAN’s public IP.
  • The primary NIC (LAN) does not receive a public IP (since AWS does not assign public IPs to instances with multiple ENIs).
  • The instance becomes completely inaccessible unless I manually attach an Elastic IP to the primary NIC.

4. Firewall Rule

• If I add allow SSH rule from the WAN security , I can once again access the server via the WAN’s public IP and if remove vise-versa will happen.

[mrmarkuz (Markus Neuberger)]

I’m trying to reproduce the issue.
How did you setup the EC2 Instance (AMI, instance type, etc…) and how did you install NethSecurity?

[Milan_Johnson]

sorry for the delay,

1. EC2 Instance Types Tested:

   • t2.micro
   • t3.micro

2. Image Preparation:

   • Downloaded the official NethSecurity image:
     nethsecurity-8-24.10.0-ns.1.5.1-x86-64-generic-squashfs-combined-efi.img

   • Converted it to VHD format using qemu-img:

     qemu-img convert -O vpc nethsecurity-8-24.10.0-ns.1.5.1-x86-64-generic-squashfs-combined-efi.img NethSecurityVD.vhd
     

3. Snapshot Creation via AWS CLI🔗:

   • Uploaded the VHD file to S3 .

   • Created containers.json file:

     {
       "Description": "My server VHD",
       "Format": "VHD",
       "UserBucket": {
         "S3Bucket": "amzn-s3-demo-bucket-name",
         "S3Key": "NethSecurityVD.vhd"
       }
     }
     

   • Imported the snapshot using:

     aws ec2 import-snapshot --description "My server VM" --disk-container file://containers.json
     

4. AMI Creation:

   • Configuration used(Created in AWS Console):

     • Architecture:* x86_64
     • Root device name:* /dev/sda1
     • Virtualization type:* Hardware-assisted virtualization
     • Kernel ID:* Use default
     • RAM disk ID:* Use default
     • Boot mode:* Use default

5. Network Configuration:

   • Assigned a security group that allows all traffic (for testing).

[mrmarkuz (Markus Neuberger)]

I didn’t manage to connect to the instance after creation.

1 Status check failed:

I’m going to retest…

[Milan_Johnson]

This is the AMI I created: ami-0526f8e8c384a6f62 in the us-east-1 region. I made the AMI publicly available.

[mrmarkuz (Markus Neuberger)]

Thanks, with your ami I was able to launch a working instance.

NethSecurity uses the 1st interface as LAN bridge and the 2nd as WAN and AWS does it’s IP assigning (public elastic whatever)
When attaching the second interface it’s a WAN interface without IP which makes NethSecurity inaccessible.

So it’s a combination of assigning IPs by AWS and default LAN/WAN config of NethSec that leads to the issue.

As a workaround you could exchange the interfaces in NethSecurity so LAN gets WAN and vice versa.
The WAN interface then gets a public IP and is reachable and the SSH rule should work correctly.

If that works for you, we could write a little howto about using NethSec on AWS.

@Milan_Johnson

Steps I Followed

1. Initial Launch

• I start an instance with a single NIC.
• At this point, both SSH and the Web UI are accessible via the automatically assigned public IP on the primary NIC (LAN).

2. Attaching a Second NIC

• When I attach a second NIC (assumed WAN) without restarting the instance:
  • The original public IP on the primary NIC (LAN) becomes inaccessible.
  • SSH and Web UI are now only accessible via the Elastic IP attached to the second NIC (WAN).

3. Reboot Scenario

• If I restart the instance while both NICs are attached:
  • Even though I accessed server using WAN’s Public IP before restart, I can’t access it through it after restart and I have to access through the LAN’s public IP.

Confirmed.

@Milan_Johnson

• The primary NIC (LAN) does not receive a public IP (since AWS does not assign public IPs to instances with multiple ENIs).
• The instance becomes completely inaccessible unless I manually attach an Elastic IP to the primary NIC.

Here the LAN interface gets a public IP that is reachable:

@Milan_Johnson

4. Firewall Rule

• If I add allow SSH rule from the WAN security , I can once again access the server via the WAN’s public IP and if remove vise-versa will happen.

I can’t reproduce. When I’m connected to the LAN interface and changing the rule doesn’t enable the WAN interface here.

[Milan_Johnson]

Hi,

When I tried again, I also had difficulty reproducing the error. However, after restoring one of the firewall configurations I had backed up during testing, I was able to successfully reproduce the issue. I also noticed that the problem tends to occur more frequently when there’s a firewall rule allowing VPN access. I’m not sure if it’s directly related to the VPN rule (port 1194), but it’s worth mentioning.

Here are the steps I followed:

---

1. Initial Test

After setting up the server, I was not able to reproduce the error, even after removing the SSH rule multiple times.

---

2. Applied Backup Configuration (Inconsistent Error Reproduction)

I then applied the following firewall configuration from one of my backups:

config defaults 'ns_defaults'
    option syn_flood '1'
    option input 'REJECT'
    option output 'ACCEPT'
    option forward 'REJECT'

config include 'ns_user_include'
    option path '/etc/firewall.user'
    option fw4_compatible '1'

config include 'ns_hs_include'
    option type 'script'
    option path '/opt/icaro/dedalo/dedalo.user'
    option fw4_compatible '1'

config zone 'ns_lan'
    option name 'lan'
    list network 'lan'
    option input 'ACCEPT'
    option output 'ACCEPT'
    option forward 'ACCEPT'

config zone 'ns_wan'
    option name 'wan'
    list network 'wan'
    option input 'REJECT'
    option output 'ACCEPT'
    option forward 'REJECT'
    option masq '1'
    option mtu_fix '1'

config forwarding 'ns_lan2wan'
    option src 'lan'
    option dest 'wan'

config rule 'ns_allow_https'
    option name 'Allow-HTTPS-from-WAN'
    option proto 'tcp'
    option src 'wan'
    option dest_port '443'
    option target 'ACCEPT'

config rule 'ns_allow_ui'
    option name 'Allow-UI-from-WAN'
    option proto 'tcp'
    option src 'wan'
    option dest_port '9090'
    option target 'ACCEPT'

config rule 'ns_dhcp_wan'
    option name 'Allow-DHCP-Renew'
    option src 'wan'
    option proto 'udp'
    option dest_port '68'
    option target 'ACCEPT'
    option family 'ipv4'

config rule 'ns_ping_wan'
    option name 'Allow-Ping'
    option src 'wan'
    option proto 'icmp'
    option icmp_type 'echo-request'
    option family 'ipv4'
    option target 'ACCEPT'

config rule 'ns_5e9d5f6c'
    option name 'Allow-SSH-from-WAN'
    option src 'wan'
    option target 'ACCEPT'
    option ns_service 'ssh'
    list proto 'tcp'
    list proto 'udp'
    option dest_port '22'
    option enabled '1'
    option log '0'

At this point, the IP address changed — I was initially using the IP assigned to the LAN, but after stopping and starting the service (sometimes even rebooting failed to reproduce the error), the system switched to the WAN IP.

---

3. Inconsistent Reproduction

After this, I wasn’t able to reproduce the error consistently.

---

4. Applied Another Backup Configuration (This gives me more Consistent Error Reproduction)

I then tried another backup configuration, which most of the times brings me back to using the WAN IP:

config defaults 'ns_defaults'
    option syn_flood '1'
    option input 'REJECT'
    option output 'ACCEPT'
    option forward 'REJECT'

config include 'ns_user_include'
    option path '/etc/firewall.user'
    option fw4_compatible '1'

config include 'ns_hs_include'
    option type 'script'
    option path '/opt/icaro/dedalo/dedalo.user'
    option fw4_compatible '1'

config zone 'ns_lan'
    option name 'lan'
    list network 'lan'
    option input 'ACCEPT'
    option output 'ACCEPT'
    option forward 'ACCEPT'

config zone 'ns_wan'
    option name 'wan'
    list network 'wan'
    option input 'REJECT'
    option output 'ACCEPT'
    option forward 'REJECT'
    option masq '1'
    option mtu_fix '1'

config zone 'ns_e2c5f479'
    option name 'rwopenvpn'
    option input 'ACCEPT'
    option output 'ACCEPT'
    option forward 'REJECT'
    list ns_tag 'automated'
    option ns_link 'openvpn/ns_roadwarrior_noremove'
    list device 'tunrw1'

config forwarding 'ns_lan2wan'
    option src 'lan'
    option dest 'wan'

config forwarding 'ns_fe43a03d'
    option src 'rwopenvpn'
    option dest 'lan'
    list ns_tag 'automated'
    option ns_link 'openvpn/ns_roadwarrior_noremove'

config forwarding 'ns_b38765cf'
    option src 'lan'
    option dest 'rwopenvpn'
    list ns_tag 'automated'
    option ns_link 'openvpn/ns_roadwarrior_noremove'

config forwarding 'ns_f615ac5a'
    option src 'rwopenvpn'
    option dest 'wan'
    list ns_tag 'automated'
    option ns_link 'openvpn/ns_roadwarrior_noremove'

config rule 'ns_allow_https'
    option name 'Allow-HTTPS-from-WAN'
    option proto 'tcp'
    option src 'wan'
    option dest_port '443'
    option target 'ACCEPT'

config rule 'ns_allow_ui'
    option name 'Allow-UI-from-WAN'
    option proto 'tcp'
    option src 'wan'
    option dest_port '9090'
    option target 'ACCEPT'

config rule 'ns_dhcp_wan'
    option name 'Allow-DHCP-Renew'
    option src 'wan'
    option proto 'udp'
    option dest_port '68'
    option target 'ACCEPT'
    option family 'ipv4'

config rule 'ns_ping_wan'
    option name 'Allow-Ping'
    option src 'wan'
    option proto 'icmp'
    option icmp_type 'echo-request'
    option family 'ipv4'
    option target 'ACCEPT'

config rule 'ns_7776fb80'
    option name 'Allow-SSH-from-WAN'
    option src 'wan'
    option target 'ACCEPT'
    option ns_service 'ssh'
    list proto 'tcp'
    list proto 'udp'
    option dest_port '22'
    option enabled '1'
    option log '0'

config rule 'ns_allow_OpenVPNRW1'
    option name 'Allow-OpenVPNRW1'
    option ns_service 'custom'
    option src 'wan'
    option dest_port '1194'
    list proto 'tcp'
    list proto 'udp'
    option target 'ACCEPT'
    option enabled '1'
    list ns_tag 'automated'
    option ns_link 'openvpn/ns_roadwarrior1'

After applying this configuration, I’m now able to reproduce the issue more consistently.

While I am using this configuration most of the time I add or remove the SSH rule, the IP address changes(after stopping and restarting).

1. This is the configuration I restored from backup
   I can access UI on 18.204.223.68

2. I deleted the ssh rule, still able to access the UI on same IP.(before restart)

3. After restarting the server, IP switched to54.167.154.225

This is elastic(static) IP by AWS, That why I am sharing the Image with IP.

[mrmarkuz (Markus Neuberger)]

I removed the public IP address from the LAN interface and just use the elastic IP for the WAN interface.
This way I connect to the WAN interface, the network config is kept after reboot and the SSH rule is working correctly when enabled/disabled.

I switched LAN to eth1 and WAN to eth0 at the interfaces page:

Here are my AWS network interfaces:

[Milan_Johnson]

Thank you for the support, and apologies for the delayed response.

I was able to resolve the issue—it turned out to be due to a network misconfiguration. The LAN interface was set to DHCP by default. Once I changed it to a static, the issue was resolved. Nothing else was changed from the default settings.

Now, the server is working as expected according to the firewall rules.

Thanks again for your help! I still don’t fully understand the difference between these settings or why this change fixed the issue. If someone could provide a brief explanation of what’s happening under the hood, I’d really appreciate it.