Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 13 replies
  • Subscribers 2 subscribers
  • Views 5936 views
  • Users 0 members are here
Options
Suggested
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

Remote webadmin?

ffeingol
I just got Astaro V8 setup (home use) and it's running great.  Is there any way to 'automatically' allow remote access to the webadmin interface or do I just need to build the appropriate packet filter rule and DNAT rules?


This thread was automatically locked due to age.
  • 0
    you can configure which networks are allowed to access the webadmin under Management->Webadmin settings->general->Allowed Networks.

    Since the webadmin is running on the asg itself, you usually don't need special packetfilter rules.
  • 0
    Or you can use a VPN client to connect to the firewall, and allow the VPN Pool(s) in the webadmin settings.

    Barry
  • 0
    I was actually surprised to find that it allowed remote access by default.  All is good and I've allowed appropriate networks to be able to access.
  • 0 in reply to ffeingol
    I am fairly new to Astaro and have a few questions that I am trying to get answered and figured out.

    One of the questions is why am I not able to access the WebAdmin with Internet Explorer 8 or Firefox 3.6 when trying to connect from a remote network through a site-to-site IPsec tunnel.

    The tunnel is up and working and I can access everything else on the remote network through the tunnel other than the WebAdmin. I went to the Management > WebAdmin>Settings and added the remote network subnet I am trying to connect from through the tunnel and still no luck?

    I have no issues accessing it when I am residing on the phsycial network?

    Thanks for any help.
  • 0

    When you have a VPN established, the public IP on the other end cannot be "seen" - you must access WebAdmin via the IP of "Internal (Address)" instead of the one via the IP of "External (Address)".

    Normally, for a domain named example.com where the internal domain is example.local, we add a forward-lookup zone example.com in internal DNS with the private, local IPs of FQDNs which otherwise resolve to public IPs in public DNS.

    As for your initial setup at work, following is what we recommend:

    Where, for example, the highest-priority MX record is mail.example.com -> 66.77.88.99, we assign 66.77.88.99 as the IP of "External (Address)" and mail.example.com as the hostname of the Astaro.

    Then, where we want to offer users external access to connect, for example, their Outlook client to their Exchange server, we create an additional address "Outlook" = 66.77.88.100 on the External interface. In public DNS, we create an FQDN outlook.example.com -> 66.77.88.100; inside the LAN, we assign outlook.example.com->172.16.1.22.

    Finally, we create a NAT rule: 'Internet -> HTTPS -> External [Outlook] (Address) : DNAT to {172.16.1.22}'.

    One other thought for a new Astaro .  Although it will be changed in V8.100, it is still possible in earlier versions to cause oneself problems by creating a host or network definition bound to a specific interface.  Just take care that all of the definitions you create have 'Interface:' >.

    Cheers - Bob

  • 0
    Well, I think I understand most of what your saying, the only thing is I was trying to connect to the Webadmin via the Internal LAN interface IP and not the public which would defeat the purpose of security because I obviously do not want to port forwad outside access to my webadmin, but I can see someone actually trying that so I do understand you bringing that up. I am also a pfsense user and they have amazing IPsec features other than not supporting NAT-T, which drives me nuts. I only bring PFsense up because you have to specific IPsec traffic on the IPsec interface before any traffic will pass. In my Astaro case, all traffic is passing and everything is accessible other than the LAN interface IP of the Astaro. The tunnel is up and running and I can access everything within the nextwork remotly over the tunnel other than the LAN interface of the remote gateway.

    I have been wondering if this calls for some sort of ipsec rule to allow remote subnets to access webadmin, but I figured I already did this when I added the remote subnet that I am accessing from over the tunnel when I added it to Management>WebAdmin Setting>General. This did not seem to do it for me.

    I am wondering if this calls for a static route. If you already gave me your answer in the last post, I appologize for not picking it up. So far I have only had 2 issues that I was not able to figure out with Astaro. You already helped me with the first issue on Web Application Security and I hope to have this one resolved as well. So far Astaro is looking very strong.

    Thanks for any help
  • 0
    You should be able to connect to WebAdmin without a route.  Do you see any related blocks in the packet filter log?  Also, whenever something seems strange, it pays to look in the Intrusion Prevention log.  If there's no hint in either of those, then maybe you could post the Astaro's IPsec log during one attempt.

    As a way to figure out where the problem might be, you could put an additional address "Phantom" on the Internal interface and then create a NAT rule:
    Traffic Source: {remote subnet}
    Traffic Service: Astaro WebAdmin
    Traffic Destination: Internal (Address)

    NAT mode: SNAT (Source)

    Source: Internal [Phantom] (Address)
    Source Service: {leave blank since not changing!}

    Automatic packet filter rule: {Checked}

    It would be interesting to know if that allowed you to connect from the remote subnet.

    Cheers - Bob
  • 0 in reply to BAlfson
    Sorry, but I am not able to get this so far. When you say Phantom Address, what do you mean?

    Thanks,
  • 0
    interesting. by default once the tunnel is up, unless you have something like a too-wide snat or dnat rule, your traffic to the webadmin (say 192.168.1.1:4444) should be completely possible. First thing, you want to be sure that you have put the proper remote networks into the permissions box for webadmin. Simply putting internal (network) will not work, you need to put the VPN pool for the method you are using for VPN. (remote network for site to site, or the apppropriate roadwarrior pool if using dial in) You say you added the remote network, i would check that to be sure you have the right ip range in there and are in fact coming from that range. Further, make sure your not natting or otherwise translating yourself on the asg so that you are really coming in from the IP address you have configured. As a quick test, try putting "any" in he webadmin allowed networks, if that works, you know where you need to make adjustments then, if not let us know.

    Also, can you ping the internal IP of the ASG itself on the lan interface without problems? if you can, then you have a route and traffic is flowing, so it is going to be some sort of permission. you dont need a packet filter rule to get to it.
  • 0 in reply to AngeloC
    I did add the remote subnet to the webadmin allowed access section. I also double checked to make sure the right subnet rage was intact as well. I am able to pink every system IP from the remote network. I al able to RDP, Proxy, etc... to any machine on my network through the tunnel. I can even access the web interface of my untangle box I have running transparently, but I cannot ping or access the webadmin internal IP interface accross the tunnel? I will try to set the webadmin to allow any and then see what happens.

    I will report back in a few.

    Thanks,