Hi all, I'm late to join this thread ;) .....

<Dinesh>
> because of the binding to MAC addresses, it would not be possible to twist
> the m0n0wall around to face the WAN in a NATted environment and then to use
> the captive portal functionality as a authentication service of sorts.

Anyhow, if Dinesh notes that the captive portal is bound by MAC+IP,
and captive portal isn't really going to work out without a serious
hack or basically redesigning the whole thing, as getting a MAC
address over the internet isn't going to work out.  I remember seeing
something on the captive portal page talking about the IP address
changing on the fly and rules would be created to let the new IP go
through.  I would assume that's done by checking the MAC address, so
like Mitch said, if all you'll see from m0n0 is the MAC of the next
hop router... it's not going to do you much good.

However, I was wondering if proxying is a viable idea in the scope of
just simple web access into the system.

For some time before I used m0n0 to secure my traffic through PPTP, I
used a proxy to get into my internal network through a SSH Port
Forwarded tunnel.  It gets a little messy, but from reading this
entire thread in the last 20 minutes, it seems to work.  It would
require some configuration on the client side, and perhaps with many
mobile users, it's really not worth the support, but...


Rather than opening up the IIS server to the Internet, you could limit
the access by putting a SOCKS proxy inside the subnet where your
server will be.  On that box will also be an SSH server.

<Mitch>
> VPN won't work for me... not sure about the other guy.... mobile
> workforce... potentially hundred of users... cost of maintaining a VPN
> solution would be big - support could be bigger - and IPSec doesn't work
> everywhere (certain hotels, etc. don't properly support passthrough.)

Now, when I did this, I used cygwin running on the Win2K box with a
SOCKS5 proxy installed.  Whether the proxy was authenticated or not
didn't matter in my case.  My SSH tunnel into the box was forwarded
from an external firewall.  (SSH tunneling works very well under
almost any situation because any traffic that runs through the
port-forward is running "on top of" SSH.)

Anyway, the client would open an authenticated SSH session, in which I
set very limited permissions what they could do on the SSH shell, and
because the fact that cygwin authenticated against domain accounts, it
was easy to manage the accounts.

After the SSH session was open with a portforward to the local proxy
server, I'd set my client to use that proxy server in the browser
configuration.  Now I could access the internal site (and any other
site for that matter) that passed the traffic through the tunnel and
to the proxy and in turn to the internal aplication server.

To make things even more complicated, you could use the Permeo driver
that takes all your traffic and transparently shoves it to a proxy
server (which was "opened" [port-forwarded is more the correct term]
by your SSH session), and then your client computer basically engages
in like a PPTP tunnel style access.


Reading this thread, I see that Michael wants to have remote users
access the web application on IIS without the rest of the internet
hitting it, so is this sounds like a working solution in case the
captive portal idea doesn't work?


Wow, this is quite a long thread o_O

/sylikc