Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 20 replies
  • Subscribers 2 subscribers
  • Views 19150 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

Astaro will not allow Network Definition using a loop back address (127.0.0.1)

coewar
Astaro v8.305
Why??  Why?? Why??????  
I try to create a Network Def for 127.0.0.1 so that I can use it, and the GUI tells me "this is a loopback address" and won't let me create it!

Another fine example of someone putting in extra effort to code something because they thought "no one will need to do this" and leaves the thing unable to do something rather than just not wasting time and effort to code something like that which would simply allow it.

My scenario which we use all the freaking time because it's totally cool and flexible, is that we SSH into a server or router and use tunnels for various things. We have a scenario where it makes perfect sense for the destination server to SSH into the Astaro router and create a remote tunnel on it, resulting in a 127.0.0.1 with some port open on the router that would let us use it to send encrypted data to that destination server. The destination server can literally be anywhere in the world.

Could have set up a nice NAT rule to make this work, but just because of this unnecessary GUI rule, I can't. Gotta find some way around it now or something.


This thread was automatically locked due to age.
  • 0
    Hi,
    This should work fine if you create a PF rule like this:

    source: Astaro External (or Internal) interface Address
    service: whatever service you're trying to tunnel to
    dest: wherever
    Allow

    NAT shouldn't be needed.

    Barry
  • 0 in reply to BarryG
    The problem with what you're suggesting (which is a NAT rule) is in the Destination of "wherever". The issue is that the "wherever" is somewhere out there and the connection between the Astaro and "wherever" is not secured. Creating a FW rule of just allowing that communication is not accomplishing anything.

    So the extremely simple and flexible solution was to have the thing at "wherever" actually make an SSH connection to the Astaro, and create a remote tunnel. That would mean that the Astaro would set the Destination to 127.0.0.1 and the service, and it would then travel through the SSH tunnel to "wherever" because that server made the tunnel.

    The other way, is to create an SSH tunnel from the Astaro to the "wherever" which is possible I think.. however #1 I'd have to add that to Astaro's cron to start it when the router gets rebooted, and #2, I still end up having a 127.0.0.1 address that I can't use via Astaro's GUI.
  • 0
    It isn't a NAT, it's a PacketFilter rule.

    Allowing traffic from Astaro out on an interface is no different, security wise, than allowing 127.0.0.1 out.

    Can you draw a diagram?
    I'm having trouble picturing the traffic flow.

    Have you considered using a VPN client to connect to Astaro?

    Barry
  • 0
    I can't draw.. [:)]  but I can describe better.

    Server Mars = a partner's server that originates traffic to us.
    Server Astaro = our Astaro router in a cloud network.
    Server Saturn = our destination server in cloud network.

    Mars sends traffic to Astaro.
    Astaro DNAT's it to make it to Saturn.

    The communication between Astaro and Saturn is not encrypted and not private.

    Communication between Mars and Astaro happens to be encrypted via an IPSec VPN.

    Saturn could have an Astaro VPN client. However this is horrifically horrible because I can't seem to get anything like that to work as a server's service. It's always assuming a human wants remote access.  But maybe there are capabilities with this I don't know. This would be a potential solution.

    Much easier solution, was to start a SSH client (as a service) on Saturn to connect to Astaro and create a remote tunnel on Astaro that points to Saturn. This has the added benefit of allowing Saturn to change IP's without anyone doing anything, since it's in a cloud network. 
    The only thing Astaro would have to do, is DNAT the traffic from Mars to go to 127.0.0.1 to make it go through the SSH tunnel to Saturn. And this traffic totally works as tested from telnet. And we use this method in non-Astaro situations.
  • 0
    If Saturn is running Linux, you should be able to configure a site-to-site VPN to Astaro with IPSEC or possibly SSL/OpenVPN.
    On Windows, I believe at least some of the remote access clients can be configured to connect on login, and reconnect on disconnect. You'd need to make sure they get the same IP every time, which is at least possible with some of the remote access VPNs on Astaro.

    Alternatively, you might want to consider a 'Virtual Private Cloud' (Amazon) or similar, so the traffic from Astaro to Saturn would be 'private'.

    Barry
  • 0
    Saturn is a Windows server. And the "some" of the remote access clients is I guess what I have to start searching for.

    All of this could have been avoided if the Astaro GUI did not have that silly restriction on creating a Network Definition of 127.0.0.1 to be used in FW or NAT rules. Such a ridiculous silly thing. About as ridiculous as not being able to set up a server load balancing rule with only 1 IP so that you can PREPARE for the fail-over balancing not just strictly "load" balancing.

    I did not specify that the cloud was on Amazon. However even so, switching to using VPC means moving the servers which is not a solution for the existing servers. We are moving things to a VMware private cloud. In the mean time, SSH tunnels is a fantastic way to get what we need. We even use SSH tunnels in the private cloud as communication end points from outside to provide an amazing amount of flexibility and resilience.
  • 0
    Astaro's SSL VPN is basically OpenVPN in a fancy configuration format. The original OpenVPN client can be run as a Windows service so the connection stays up as long as the machine is running.
  • 0 in reply to ChrisH1
    Astaro's SSL VPN is basically OpenVPN in a fancy configuration format. The original OpenVPN client can be run as a Windows service so the connection stays up as long as the machine is running.


    The problem with that is that I have not found how to allow the Astaro SSL VPN users get in with configuring OpenVPN to run as a service and not prompt for a password. I'm not an expert in this part, but searching the internet and this forum has not found me with a way to do it.
  • 0
    Ah. You'll need a specially compiled OpenVPN binary for that - the default build doesn't allow storing username and password in the config file.
    I think someone in the OpenVPN forums might be able to help you out there.
  • 0
    Why do you want to secure the traffic between Astaro and Satrun, but its okay to be insecure from Mars to Astaro?

    BTW, Windows 2003 is able to do IPsec.
    How To Configure IPSec Tunneling in Windows Server 2003