Can't access SSH, WebAdmin, etc from remote location

This may seem like a simple question, but, do you have 2 interfaces ? One external and one internal ?

Mike

Yes, eth0 is internal, eth1 is external; both are up.

Some more detail:

Settings: WebAdmin: Allowed networks = Any
Settings: SSH: Status = On
Settings: SSH: Allowed networks = Any

Interfaces: Default Gateway: Preference order =
  eth0
  eth1
  eth1_masq_aaa_pdc (for SNAT/DNAT)
  eth1_masq_aaa_emma2 (for SNAT/DNAT_

I have played with the preference order, and this is the setup that seems to work, at least for internal to external NAT.

Routing table:

code:

---

xxx.xx.xxx.xx/26 dev eth1  scope link 
192.168.1.0/24 dev eth0  scope link 
127.0.0.0/8 dev lo  scope link 
default via 192.168.1.1 dev eth0 
default via xxx.xx.xxx.xx dev eth1 

---

NAT/Masquerading rules:

code:

---

  
LAN / Private_Network_192.168.0.0 -> All / All   MASQ__eth1 / none
SMTP-IN / Any -> eth1_Interface__ / SMTP   MASQ__eth0 / AAA-PDC

---

My temporary (very open) rules:

code:

---

  1  { Private_Networks_-_RFC1918 } HTTP Any Allow  
  2  { Private_Networks_-_RFC1918 } HTTPS Any Allow
  3  { Private_Networks_-_RFC1918 } SSH Any Allow  
  4  Any Any Any Allow
  5  Any SMTP AAA-PDC Allow

---

ICMP on Firewall = On

Bottom line, you should be able to ping this box and SSH to it just like any other box on the same switch using the same subnet.

FYI, this system is just installed and has a trial license.

Any help is very much appreciated.

Just at a quick glance...

You should only need a Default Gateway on those interfaces which have an upstream internet connection.  Adding a default gateway to an interface implies to the kernel's routing table (or the routing processes on most/all hardware routers) that a default route be added utilizing that interface as an egress/outgoing path to the "default" route.  What this means is that you should see routes in your routing table for the same subnets that each of your interfaces is in, called Connected Networks, plus any Static Routes that you entered, and finally, a default route that uses your defined default gateway(s).

The precedence for most TCP/IP stacks is to use the most specific route (from the most highly trusted source) first, then anything more general only if the specific path is unkown.  When I say "most highly trusted", this only applies when several different methods or protocols are used to learn/advertise routes.  In the case of probably 99.9% of all Astaro implementations (anyone using Zebra/GateD please speak up), the *only* methods to "learn" routes is by (a) defining a default gateway, (b) adding a static route, and (c) relying on the path being included within the scope of the connected networks, meaning in the same subnet as defined on any of your firewall's interfaces.

What this all means is that some IP address not able to be ARP'd out as being on a locally attached subnet, and further not defined in any static routes, would have to rely upon there being a default route in the kernel's routing table.  In the case of the same 99.9% of all Astaro boxes, only your external interface should have a default gateway assigned.  Because, in effect, you cannot get to any IP address via your internal interface.  Only your external interface and, further, your provider's network should be able to get you to anywhere.

I can't say for certain that, by correcting this, your specific problem will be solved.  However, by making this change may likely minimize any troubleshooting grief down the road.

I hope this helps!

Rob