Re: NAT implementation in an IM driver
From: Maxim S. Shatskih (maxim_at_storagecraft.com)
Date: 06/16/04
- Next message: Maxim S. Shatskih: "Re: Passthru problems at Distpatch_Level"
- Previous message: Tojo: "Passthru problems at Distpatch_Level"
- In reply to: Alex the 1'ts: "Re: NAT implementation in an IM driver"
- Next in thread: Alex the 1'ts: "Re: NAT implementation in an IM driver"
- Reply: Alex the 1'ts: "Re: NAT implementation in an IM driver"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 16 Jun 2004 14:08:07 +0400
The NAT you're planning is an IM driver between the "world" NDIS adapter of
the router and the IP stack. It even must not filter the "internal" adapter.
In this case, you do not need any MAC address chemistry, since the IP
router is also employed, and does its work. Just translate the addresses and
port numbers, and do not forget to recalculate the checksums. For functionality
description, look at "ipnat" manpage in FreeBSD - it is very good.
After all, the "world" interface of the router can have some media type
other then Ethernet - like native ATM or 1394. In this case, the IM writing is
a huge PITA, since IP1394 and native ATM use the custom ARPs, and the interface
between them and their NDIS adapters is not documented (it uses custom NDIS
media types and packet formats).
For PPP, MS was so kind to expose it as fake Ethernet :) PPP also uses the
custom ARP, but the packet format between WANARP and NDISWAN is fake Ethernet
(with some fake data in MAC addresses fields), so you can plug an Ethernet IM
driver there with not so large amount of work - or even "as is".
-- Maxim Shatskih, Windows DDK MVP StorageCraft Corporation maxim@storagecraft.com http://www.storagecraft.com "Alex the 1'ts" <AlX@a> wrote in message news:%23AreDb4UEHA.3664@TK2MSFTNGP12.phx.gbl... > When the user sets your system as the gateway, on his system the packets > that are sent to non-local addresses are sent to your MAC, not the target > MAC, so when you route them, you need to send them to your GateWay MAC, so, > you do need to change the destination MAC address. > > > > This is why I think he would be better off in user mode; where you can > resend the packet using the standard windows IP stack. > > "Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message > news:%23zoUn13UEHA.2944@tk2msftngp13.phx.gbl... > > > To implement NAT in an IM driver, besides translating IP, ports, > adjusting > > > checksums, a new Ethernet header needs to be constucted. > > > > Why? You can leave the Ethernet header "as is". > > > > -- > > Maxim Shatskih, Windows DDK MVP > > StorageCraft Corporation > > maxim@storagecraft.com > > http://www.storagecraft.com > > > > > >
- Next message: Maxim S. Shatskih: "Re: Passthru problems at Distpatch_Level"
- Previous message: Tojo: "Passthru problems at Distpatch_Level"
- In reply to: Alex the 1'ts: "Re: NAT implementation in an IM driver"
- Next in thread: Alex the 1'ts: "Re: NAT implementation in an IM driver"
- Reply: Alex the 1'ts: "Re: NAT implementation in an IM driver"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
