NDIS IM and NAT

Hello, All!

I am trying to develop a NAT server using my NDIS IM driver.

Within ProtocolReceive() I change packets' IP address and port numbers,
update checksums, and indicate it up.

But seems like packets are not getting to destination.
Could anybody tell me why this may happen?
I do not change mac adresses - is that a problem?
Or do I need to NdisSend packet instead of indicating it?

Thanks.

Best regards,
serge

Thomas
Wed Nov 23 20:10:41 CST 2005


"pserge" <pserge@ipnet.kiev.ua> wrote in message
news:dm30qb$2ho2$1@news.dg.net.ua...
> Hello, All!
>
> I am trying to develop a NAT server using my NDIS IM driver.
>
> Within ProtocolReceive() I change packets' IP address and port numbers,
> update checksums, and indicate it up.
>
> But seems like packets are not getting to destination.
> Could anybody tell me why this may happen?
> I do not change mac adresses - is that a problem?
> Or do I need to NdisSend packet instead of indicating it?
>
> Thanks.
>
> Best regards,
> serge
>

Could be that the packet is malformed. The first buffer must include the MAC
header and the lookahead data or it will be ignored. See NDIS.com:

http://www.ndis.com/pcakb/KB01060101.htm

It could also be incorrect handling of NDIS Task Offload. See NDIS.com:

http://www.ndis.com/pcakb/KB05280101.htm

Also see the NDIS Packet Discussion at NDIS.com.

Good luck,

Thomas F. Divine, Windows DDK MVP
http://www.pcausa.com

pserge
Thu Nov 24 14:22:49 CST 2005

Hello, Thomas!
You wrote on Wed, 23 Nov 2005 21:10:41 -0500:

Please find my comments below.

>> I am trying to develop a NAT server using my NDIS IM driver.
>>
>> Within ProtocolReceive() I change packets' IP address and port numbers,
>> update checksums, and indicate it up.
>>
>> But seems like packets are not getting to destination.
>> Could anybody tell me why this may happen?
>> I do not change mac adresses - is that a problem?
>> Or do I need to NdisSend packet instead of indicating it?

> Could be that the packet is malformed. The first buffer must include
> the MAC header and the lookahead data or it will be ignored. See NDIS.com:
> http://www.ndis.com/pcakb/KB01060101.htm

1) I am using single NDIS_BUFFER for entire packet.
2) Tried to set NDIS_STATUS_RESOURCES - no luck.

> It could also be incorrect handling of NDIS Task Offload. See NDIS.com:
> http://www.ndis.com/pcakb/KB05280101.htm

I return NDIS_STATUS_NOT_SUPPORTED for OID_TCP_TASK_OFFLOAD...
Also, UDP packets are not getting to destonation, as well.

Do I need to change only IP and port in order to implement a NAT?
Should I indicate packet to different adapter instead of that one, I
received it for?

As for me, such behavior I faced is correct, but not one I want to achieve.

(A) --> (B with NAT) --> (C)

TCP stack (B) receives modified packet from (A), checks its destination IP
addres, that does not belong to the same computer, and drops it. Am I right?

Serge.

Thomas
Thu Nov 24 18:41:59 CST 2005


"pserge" <pserge@ipnet.kiev.ua> wrote in message
news:dm58e2$7ov$1@news.dg.net.ua...
> Hello, Thomas!
> You wrote on Wed, 23 Nov 2005 21:10:41 -0500:
>
> Please find my comments below.
>
>>> I am trying to develop a NAT server using my NDIS IM driver.
>>>
>>> Within ProtocolReceive() I change packets' IP address and port numbers,
>>> update checksums, and indicate it up.
>>>
>>> But seems like packets are not getting to destination.
>>> Could anybody tell me why this may happen?
>>> I do not change mac adresses - is that a problem?
>>> Or do I need to NdisSend packet instead of indicating it?
>
>> Could be that the packet is malformed. The first buffer must include
>> the MAC header and the lookahead data or it will be ignored. See
>> NDIS.com:
>> http://www.ndis.com/pcakb/KB01060101.htm
>
> 1) I am using single NDIS_BUFFER for entire packet.
> 2) Tried to set NDIS_STATUS_RESOURCES - no luck.
>
>> It could also be incorrect handling of NDIS Task Offload. See NDIS.com:
>> http://www.ndis.com/pcakb/KB05280101.htm
>
> I return NDIS_STATUS_NOT_SUPPORTED for OID_TCP_TASK_OFFLOAD...
> Also, UDP packets are not getting to destonation, as well.
>
> Do I need to change only IP and port in order to implement a NAT?
> Should I indicate packet to different adapter instead of that one, I
> received it for?
>
> As for me, such behavior I faced is correct, but not one I want to
> achieve.
>
> (A) --> (B with NAT) --> (C)
>
> TCP stack (B) receives modified packet from (A), checks its destination IP
> addres, that does not belong to the same computer, and drops it. Am I
> right?
>

Well, the received NATed packet must be indicated to TCP on the adapter with
IP address matching the NATed packet's destination IP address.

In addition, for directed receive packets the destination link address must
be the MAC address of the adapter that the NATed packet is being indicated
on.

The rules are a little different for broadcast and multicast packets. Study
broadcast addressing for both the link and the IP level.

Good luck,

Thomas F. Divine, Windows DDK MVP
http://www.rawether.net

Maxim
Thu Nov 24 18:55:52 CST 2005

> Do I need to change only IP and port in order to implement a NAT?
> Should I indicate packet to different adapter instead of that one, I
> received it for?

No, only IP and port.

NAT works for a particular adapter. Its usual rules are:

- the NAT entry is - internal IP/port, external IP/port
- if the incoming packet's dst IP/port matches the external IP/port of some NAT
entry - then the packet is patched, and its dst IP/port are replaced with
internal IP/port of the same NAT entry.
- if the outgoing packet's src IP/port matches the internal IP/port of some NAT
entry - then the packet is patched, and its src IP/port are replaced with
external IP/port of the same NAT entry.
- if the outgoing packet is TCP SYN and there is no NAT entry for it - it is
dynamically created, the internal IP/port are taken from the src IP/port of the
packet, the external IP is the IP of the interface on which the NAT is
listening, and the external port is some unique value which do not clash with
other NAT entries. Then the packet is patched against the same rule, as any
other outgoing packet.

Such a NAT can be implemented below TCPIP.SYS.

Read the FreeBSD's manpages on "natd" and "ipnat" for more ideas.

NOTE: for some protocols like ICMP, FTP and some others, you will need to patch
the data too, since they transmit the IP addresses within the data payload (FTP
does this on PORT command and PASV response).

IPSec (and thus L2TP) cannot work thru NATs.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

pserge
Fri Nov 25 10:29:58 CST 2005


Hello, Maxim!
You wrote on Fri, 25 Nov 2005 03:55:52 +0300:

MSS> NAT works for a particular adapter. Its usual rules are:

I understand how NAT _should_ work... But it does not.

Could you tell me what should I do with rewrapped packet?:
(1) Should I indicate it up? What miniport handle should I use? The same
one, or that one, connected to the internet (assuming the packet received
from private network)?
(2) Or, should I send it right away (with NdisSend())?

The problem is that the rewrapped packet is ignored if I inducate it up with
the same miniport... :(

Serge