MAC and gateways

Hi,

I have a problem regarding preservation of MAC addresses in packets
when they cross gateways.
My question is basically if it is possible to preserve the MAC address
somehow as the packet cross the gateway.
F.ex. I have the following setup:

internet
|
ip public
Linux Server
ip 10.0.0.1
|
ip 10.0.0.2
Router A (linux based)
ip 10.0.1.1
|
10.0.1.2
Router B (linux based)
10.0.2.1
|
10.0.2.2
Client (linux based)

So if the Client sends a packet to the Server, I notice that the MAC
address of the packet as it is reaching the Server is no longer the
MAC of the Client, but equals the MAC of Router A ip 10.0.0.2

I am designing a special system, where I need to authenticate the
Client based on the MAC address and the IP of the Client (so only to
let the packet thru at the server if MAC and IP matches an entry in a
table). But if the MAC address changes then this is a problem
obviously.
So is it inherent in the protocols that the MAC changes over a
gateway, or can I change the routing somehow maybe? or can I do some
magic with the ARP tables? I should mention I have full control of all
the servers and routers and clients in this setup so a hack can also
work :-) just not really sure how to attack this problem. If it helps,
the Routers and the Clients are running RouterOS (Mikrotik), the
Server is running RH 9
Any help/ideas would be appreciated. Thanks.

Regards,
Tobias

On Feb 20, 9:24 am, "nsa....@gmail.com" <nsa....@gmail.com> wrote:
> Hi,
>
> I have a problem regarding preservation of MAC addresses in packets
> when they cross gateways.
> My question is basically if it is possible to preserve the MAC address
> somehow as the packet cross the gateway.

In general, no, it is not possible to preserve the original MAC
address in such a configuration.

If you rebuild your network such that the source and destination are
on the same network segment (say, using a VPN or a Point-to-point
link) or you change your application to carry the MAC address as part
of the data payload, you should be able to do what you intend.

[snip]
> I am designing a special system, where I need to authenticate the
> Client based on the MAC address and the IP of the Client (so only to
> let the packet thru at the server if MAC and IP matches an entry in a
> table). But if the MAC address changes then this is a problem
> obviously.

OK, so you've designed your authentication in such a manner that you
will have to make some compromises with either your network design or
your application design.

MAC addresses are only usable (in terms of the on-the-wire packet) on
the local network segment. In that context, they are used by each node
on the network segment to determine physical routing. Such addressing
is unnecessary and unavailable outside of the lan segment; the role of
the gateway is to move data packets from one segment to another, and
this means that it rebuilds the network packet (including MAC address)
for each packet so moved.

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

On Feb 20, 5:48 pm, "Lew Pitcher" <lpitc...@sympatico.ca> 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

> 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

Oh actually I see now that the original MAC is not kept in the
ethernet header :-( would have been a nice feature though (especially
for bigbrother! heh)

Tobias