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

License not releasing unused IPs, even after a few weeks

Hello everyone,

I am a fresh adopter (switched from pfSense a few months ago), and found ASG to be a wonderfull product.
I'm using the software version, with a home license.

I'm facing a little issue at the moment : the license counter tells me that 49 IPs (of 50 available within the license) are used.

I know that unused IPs are supposed to be "released" 7 days after they've been seen for the last time.
However, I'm still seeing old IPs in the "active IP addresses" tabs, even weeks after I've shut down the corresponding machines!
(And I'm pretty sure these machines are fully shut down for more than 7 days, for they were VMs on my laptop that I erased last month)

Is there a way to refresh this "active IP addresses" counter?
I've read in the forums a few tricks, such as reinstalling the software and restoring a backup, or simply restoring a backup at boot time (with a clear backup at the USB key's root).
I'm not very pleased to perform the 1st option, and I don't know how to launch the 2nd one : when I start the machine with a USB key containing the backup, it boots normally. Nothing happens (backup is on the key's root directory, has no password, key is a 8 GB model, fat32-formatted).

Could someone provide me a little help here, please?
Thanks a lot in advance!


This thread was automatically locked due to age.
  • Hi, Vasteel, and welcome to the User BB!

    Is your Astaro a VM?  Version 8.305?

    You should be able to go to 'Management >> Backup/Restore' and restore from a recent backup, or just make a new one and restore from that.  I bet that won't change things though and that a re-install from ISO will be necessary.  This isn't a common problem, so I wonder if the virtual NICs aren't still active on your laptop.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Thank you for your reply. [[;)]]

    Yes, I'm running v8.305, but on physical hardware.
    (Was first running on a Hyper-V host, but crashed virtual switches every time I transferred more than 40-50 GB of data. There is a topic concerning this issue, but no solution seemed to be found at the time)

    I erased the VMs (old 2k3 VMWare VMs replaced by 2k8r2 Hyper-V ones with different IPs), and the laptop is in its bag since then, so I'm pretty sure the ASG couldn't have seen their IPs routing somewhere in the past 7 days. [[;)]]

    Well... I'll try to reinstall the whole thing and see what happens.
    Thanks again for the tips!
  • I finally had time to reinstall everything last week-end, and let the ASG run for a few days.
    Things were going better, but since yesterday, there is a new IP in the list, and I'm 100% sure the ASG can't have seen it.

    It's "192.168.0.2" : in this IP range, there is no DHCP, IPs are fixed manually starting at 192.168.0.160, and there is only 1 Hyper-V host connected to this interface, running 7 VMs.

    I double checked the Hyper-V server and the VMs : none of them are using a secondary IP address.
    I also ran a few tests using Wireshark and Fing : not a single trace of this IP around this part of the network.

    Is there a way of checking from which interface and when this IP has been seen by the ASG?
    (I can't find a single occurence in the "firewall"-named log)

    Thanks in advance for any help!
  • You can use various reports and tools in Logging & Reporting to find the traffic that was seen to/from this IP.  Something else that may be helpful, which is run from the shell, is arping.  With this tool, you can find out if the host is "alive" and the mac address.
    __________________
    ACE v8/SCA v9.3

    ...still have a v5 install disk in a box somewhere.

    http://xkcd.com
    http://www.tedgoff.com/mb
    http://www.projectcartoon.com/cartoon/1
  • Okay, thanks a lot for the tips, I saw where it came from.
    I saw in the reporting server the port that this IP used, and this is the specific port from a peer-to-peer tool I use on a specific VM.

    So I checked the logs from this tool, and saw that some packets sent from outside clients were malformed (tagged with a class C IP address).
    I think the ASG simply thought the IP came from the inside...

    Well, I guess something should be done there in the ASG to be able to differentiate IPs coming from the inside or the outside when counting license usage. [;)]

    In the meantime, I'll try to add a rule in the firewall to check packets from the outside tagged with internal IPs, and block them...
    I had this kind of rules available by default with pfSense. Is there some best practice to add them in the ASG?

    Again, thanks a lot in advance for the help!
  • By default, the Astaro blocks everything, so one of your Firewall rules must be allowing that traffic.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • I was thinking about the "block bogon and RFC1918 networks on pubic IP interfaces" rule from pfSense.
    Since this rule is top first in the list, any other permissive one is overridden within these IP ranges.

    I'm not an expert in firewall rules hardening nor preventing spoofing, so I'll take any advice considering this issue. [;)]
    (I still wonder how a packet from the outside could have been routed to my DSL line, considering the source is a non-NATted private IP. But as I said, I'm not an expert)

    Well, here is a simple overview of my network:
    DSL router > front firewall > Astaro ASG > service offering VM
    (The service runs on TCP 5005 port)

    So the packet is allowed within the following rules:
    In the front firewall:
    any IP, TCP 5005 > DSL public IP, D-NAT to Astaro ASG, TCP 5005
    In Astaro ASG:
    any IP, TCP 5005 > Astaro ASG "public IP facing adapter", D-NAT to service offering VM IP, TCP 5005

    I can't really exclude a specific range within a rule definition, from the front firewall (I'm not sure I can in the ASG either).
    So here's the operations I did:
    - defined an IP group containing ranges from RFC1918
    - placed the following rule : RFC1918, TCP 5005 > DSL public IP, drop

    Do you think that will be enough? Do I need to consider additional operations?
    Thank you in advance for all the help and tips!
  • "block bogon and RFC1918 networks on pubic IP interfaces"

    bogon? [[;)]]

    You can reproduce the RFC1918 block with a single Firewall rule:

    {Network Group containing 10/8, 172.16/22 & 192.168/16} -> Any -> External (Network) : Drop



    (I still wonder how a packet from the outside could have been routed to my DSL line, considering the source is a non-NATted private IP. But as I said, I'm not an expert)

    I had the same thought.  That's likely the DSL modem provided by your ISP.  I see my cable modem occasionally passing a 10. address that appears to be its addresss in my ISP's network.

    Cheers - Bob
    PS I just read the rest of your post, and I think that's exactly what you suggested.  Your network Kung Fu is strong. [[;)]]
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • My ISP (TW) seems to use 10.x addresses for their DHCP servers and other infrastructure.

    Barry
  • bogon? [[[;)]]]

    Never took the time to check on Wikipedia's definition, but I learned a word, today. [[[;)]]]

    PS I just read the rest of your post, and I think that's exactly what you suggested.  Your network Kung Fu is strong. [[[;)]]]

    Thanks.

    I've put the rule a few days ago and let the service run for a while.
    I just checked the license count, and there no "unknown" IP showing.

    Even the 192.168.0.2 coming from the outside has disappeared, so everything is running fine, now!

    Thanks a lot for all the help!