Home User with 20+ IPs

I have a fairly elaborate combined home office and test network, containing several subnets, with 20+ systems, counting the PCs, the servers, the intelligent switches, the UPS with the Ethernet interface, etc. However, my 10 user ASL v4 home user license hasn't been a roadblock for me so far. At any given time, there are only 3 to 5 machines that are communicating out through the ASL box, so I am not even close to hitting my limit.

Until it becomes a real problem, I would suggest not worrying about the home license connection limit.

Cool...thanks for the replys.

Yeah things are working fine now.  My connection log has been as high as 19 hosts.  There isn't any pop-up or alarm showing on the WebAdmin so I guess they are allowing this for now...which is definitely a good thing.

I received a quote back from sales that was still too high.  Oh well!

i'm not a gamer, but what about lan-parties etc? i think that today 10 ips are a joke, because every thechnical stuff (dvd, hometheater, mp3-station, coffee-machine, etc) has an ethernet port, so reaching the limit of 10 ips could happen verry soon for real homeusers, too. don't forgett about "bigger" families or student-apartments.

It isn't the number of Ethernet cards and devices on your LAN with an assigned IP address that consumes ASL license slots, it is the actual number of different IP addresses that are simultaneously communicating out through the ASL box to the outside world.

If your LAN party is strictly local, where the machines are communicating with each other, but are not going outside to the Internet, you shouldn't have a problem.

[ QUOTE ]
It isn't the number of Ethernet cards and devices on your LAN with an assigned IP address that consumes ASL license slots

[/ QUOTE ]

i didn't say that

but what about vpn parties ? or if friends want to surf or do other things while gaming?  

VelvetFog, my experience is that if you use ASL for DHCP, all DHCP clients will be counted.

Also, clients don't have to be simultaneous, as ASL seems to remember them at least until reboot.

Barry

Not neccessarily true. I have licenses counted just by a machine sending out a broadcast to 255.255.255.255 .

Not neccessarily true. I have licenses counted just by a machine sending out a broadcast to 255.255.255.255 .

And the current behaviour I see is that just about any traffic that hits the interface bumps up the IP count, whether or not it tries to go through it. For instance, I have a development network with only five devices on it. Even the ARP cache tells me so...yet I am routinely getting IP counts of over 120! Yeah, right! It's a dead-end network, too, so I obviously cannot trust the IP counts the ASL is reporting since there's no way that number of IPs could have originated from the back network.   I flatly refuse to believe this firewall's IP count.   This is not the only one I've seen with this problem. Of the SEVEN ASL boxes I run, I see this on three of them. (And one of them is unlimited, so it doesn't even bother counting!)

I think you could easily mitigate your IP count problem by using a proxy on your network. If most of your clients are going through the firewall just for HTTP, then just point them all to a single host and you'll immediately get a drop in your IP count. I would argue that you're then using services provided by a separate system and are therefore not using the firewall services of the ASL to provide for the end clients. Hence, you are validly using the product.

[ QUOTE ]
And the current behaviour I see is that just about any traffic that hits the interface bumps up the IP count, whether or not it tries to go through it. For instance, I have a development network with only five devices on it. Even the ARP cache tells me so...yet I am routinely getting IP counts of over 120! Yeah, right! It's a dead-end network, too, so I obviously cannot trust the IP counts the ASL is reporting since there's no way that number of IPs could have originated from the back network.   I flatly refuse to believe this firewall's IP count.   This is not the only one I've seen with this problem. Of the SEVEN ASL boxes I run, I see this on three of them. (And one of them is unlimited, so it doesn't even bother counting!)

I think you could easily mitigate your IP count problem by using a proxy on your network. If most of your clients are going through the firewall just for HTTP, then just point them all to a single host and you'll immediately get a drop in your IP count. I would argue that you're then using services provided by a separate system and are therefore not using the firewall services of the ASL to provide for the end clients. Hence, you are validly using the product. 

[/ QUOTE ]

You could have a look at /opt/tmpfs/alicd.dump, chapter "*LUSERDB" and tell us, why your IPs have been counted (the hash-commented lines). Probably you opened your internal networks for traffic from the Internet.

And yes: if you really proxied your network the way you describe, that solution would take only one licensed IP. But that doesn't seem to scale well, does it?

My LUSERDB (I love this!  ) shows that hosts behind the firewall are being accessed from many hosts across my WAN. This is not surprising since they are providing services. How is this any different than any of my other firewalls on the outside of my network. (This fw is on the inside, so all addresses it sees are RFC1918 addresses).

[ QUOTE ]
My LUSERDB (I love this!  ) shows that hosts behind the firewall are being accessed from many hosts across my WAN. This is not surprising since they are providing services. How is this any different than any of my other firewalls on the outside of my network. (This fw is on the inside, so all addresses it sees are RFC1918 addresses). 

[/ QUOTE ]

Hi,

 The idea behind the keyword seems to have been  "Licensed users DB". Perhaps that should be renamed to WINNERDB.

But now back to our topic: Could you please explain your network topology in more detail? If you think that would go too far for this forum, feel free to contact me by PM, and we could summarize here afterwards.