This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

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

No matter what I do, I can't access the firewall box from outside the network. Everything seems to be set just right, and nothing shows on any of the real time log views. Ping also fails from outside despite  ICMP being switched on and working perfectly inside the network on the same interface/ip.

This is really weird, since outgoing NAT style connections also all work great.

Any ideas?


This thread was automatically locked due to age.
Parents
  • 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.
Reply
  • 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.
Children
  • 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