Re: MAC and gateways

On Feb 20, 5:48 pm, "Lew Pitcher" <lpitc...@xxxxxxxxxxxx> wrote:


So, to get your packets to carry the original MAC address, you are
either going to have to circumvent the gateway by putting the target
system on the same lan segment as the source system (by a point-to-
point link or a VPN of some sort), or you are going to have to carry
the original MAC address as data.

Sorry
--
Lew

Hey, thanks alot for clearing that up. I had a notion this was the
case but it makes alot of sense offcourse.
Basically the system is for authenticating access to the internet for
the Client thru the Server and is based on something called Sesame
which is based on NoCat. The Client is actually a wireless hotspot
with the Users connected to it. This inherently checks IP address and
MAC and allows packets thru or not, but obviously I realize now it
doesn't scale to beyond a single segment. Now I'm thinking of two
options, 1 the VPN option which you suggested, I like and will look
into or second authenticating purely on the IP address. I would like
to know if you (or anyone else) thinks thinks this is a good idea (the
second option).
The Client will use the system in sessions of a few hours. He buys
tickets with username/passwords that are good for 1 hrs to 10 hrs.
When he first tries to access the internet he is rerouted to a splash
page on the Server and asked for username/password the server notes
down the IP address (and untill now also the MAC) and allows access
through the firewall (i.e. all packets with that IP (and MAC) allowed
though). The Client keeps the current window which now says 'logged
in' open because that window refreshes every 2 mins and therefore the
server knows to keep allowing him access through the server. If the
Client closes the 'logged in' window the Server will disconnect him
within 2 mins.
So the question is this, if only authenticating on the IP address and
I remove the MAC check, then what are the real issues regarding
someone getting unautherized access? I guess someone could spoof the
IP of someone else, but what would that gain him? yes, his packets
would go out, but can he get packets back? would spoofing not just
confuse the legitimate Client with the same IP and make that client
try to re-connect? Also, in theory if a client disconnects, there is
a 2 min window that an intruder can take advantage of with spoofed
packets using the same IP as the client and get packets back again
without any confusion (as there is now no other machine with same IP
in the network), and possibly there would be a way to therefore keep
the connection 'open'. But, if someone can spoof the IP, he should be
able to also spoof the MAC anyway, he could sniff the net and change
hos own MAC to what he sees in some packets and therefore hijack the
connection anyway. So I'm thinking by loosing the MAC check then I'm
not really loosing that much in actual real-life security? Or what do
you think?

I'll be checking out the VPN option though, but I'm thinking now it
will be the same problem unless the VPN extends all the way to the
actual User (which is not possible). Offcourse I hadn't mentioned this
in my previous mail so you couldnt have known this. If the VPN is only
to the Client (i.g. the wireless hotspot) then the MAC would still
only be that of the hotspot and not of each individual user that is
connected to the hotspot, right? unless there is a way to hack this?
The Clients are running RouterOS by the way and many things can be
done in that but not so much hacking I think.

A third question now springs to mind though: Is the original MAC still
embedded in the IP package? or is there a way to embed this somewhere
in the header? if so, the Server could theoretically check for this
embedded MAC in the firewall (I'm using iptables) instead of looking
at the actual MAC of the packet.. hmmmm.....

Tobias

.

Relevant Pages

  • Re: Mac file names too long??
    ... > Thank you for posting in SBS newsgroup. ... > networking settings on the MAC; modify the directory service options; ... > some settings on the SBS server need to be changed. ... > I. Check the TCP/IP properties of the MAC client. ...
    (microsoft.public.windows.server.sbs)
  • RE: Mac file names too long??
    ... Thank you for posting in SBS newsgroup. ... Generally speaking, for the SBS 2003 domain with MAC clients, some ... You can check the white paper and ensure both the server and the clients ... and client correctly: [note: please notice the ISA section of the bottom of ...
    (microsoft.public.windows.server.sbs)
  • RE: MAC client cannot access web site via ISA 2004
    ... I understand the issue to be: MAC client cannot ... browse the web site on web server which you have published. ... Generally speaking, for the SBS 2003 domain with MAC clients, some ...
    (microsoft.public.windows.server.sbs)
  • Re: Questions about serving database
    ... recommended a PC over a Mac. ... specs for a computer, and if my client environment is almost all mac, ... I've set up my database with a data file, ... Point in Space is perhaps the most well-known server, ...
    (comp.databases.filemaker)
  • Re: MacSrv Event ID 12061 Errors
    ... Connections can be slept on a per connection basis - the Mac client may or ... monitor tool on the server and looking at the time stamps of the traffic ... Mac clients will prefer afp over TCP/IP if the server supports it. ...
    (microsoft.public.win2000.macintosh)