I'm setting up a ip-authentication mechanism for tomcat. To do this, I'm using request.getRemoteAddress() to get the address from the http request.
Only problem is, it doesn't seem to be working. For example, when I connect from my machine (which has a static ip), I get another ip address in my provider's block.
I understand that providers sometimes cache web pages to lessen network traffic. Maybe this is having some effect?
In any event, does anyone know how to get the REAL ip address of the client?
I was investigating this issue with my provider, figuring that they might know SOMETHING about it. Turns out I was correct. My supposedly "static ip" is only static in one direction.
> If you require IP-based authentication or have some other IP-specific
> applications you would need to convert to what's called a
> VPN-compatible IP address. These are $10/month.
> Consumer-grade accounts all get a dynamic proxied IP address by default.
DHCP BTW, works by offering the client a "lease". The address they get is good for a preset time interval and then the lease must be renewed. Often the lease expires after the user has shut down and they end up with a different address (statistically) next time they come online.
You start getting a few dozen workstations and it's easier to use DHCP than assign everyone an IP manually. Usually the pool that these IPs comes from is one of the "private" IP ranges, like the 10.x.x.x or 192.168.x.x that cannot be used directly on the Internet - users go through NAT or a proxy that links them via a "public" IP.
Yes, I've got this exact setup running at my house through a $150 router, hooked up to dsl. The thing that surprised me is that I thought I was purchasing a "static ip" from my provider. So under my current setup, I can run a web server, but since I'm running through a proxy it's not "static" in the other direction.
However, the company that is has requested ip-based authentication access (to this subscription site) is tied together with a vpn. They have one or two distinct ip's per office. So they're already set up for it.
In this case, I believe that this authentication mechanism will work. But for those of us with "consumer-grade accounts", this approach obviously will not work.
Since Windows Security is such an oxymoron, I make all the Windows machines actually run on their own subnet behind a second firewall. I can run DHCP there with no problems.
The local AT&T cable modem system runs customers under DHCP, BTW, even though it's an "always on" setup.