Hello Experts,
We have an NDIS 5.1 driver which should redirect the outgoing http traffic to a proxy server on the localhost. Our driver clones the packet and stores it’s original source port (to redirect the answer backward). We modify the destination IP, MAC and port parameters. If we do not modify the destination MAC, the NDIS driver sends the packet to the network and some routers drops it, so we have to modify it too. After then we regenerate the TCP and IP checksums and forward the packet. We do the same for the incoming (answer) packets. We can identify them from the port that we stored before.
This procedure works only if we modify the route and the arp table. So we have to add the following lines:
route add [local.ip] mask 255.255.255.255 [local.ip] metric 1
arp -s [local.ip] [local.mac]
On XP machines this procedure works fine in most cases (only one machine had problem, but it worked fine before too), but the Vista and 7 machines has strange problem.
After a while the arp entry switches to invalid and disappears and then the whole redirect procedure fails.
The only one XP machine does the same. It sends to the network the gratuitous arp query and after then the arp entry disappears.
Any idea would be greatly appreciated!
Thank you in advance!
I think you are missing some rather important points about the role NDIS &
the NIC play vs. what TCPIP does.
Changing anything in the transport header or payload (TCP) or IP header will
have no effect (ignore offload for the moment) on how a packet is processed
by NDIS and/or the NIC driver. Changing the destination IP address to a
local address does not mean that the packet will be looped back by the NIC.
Even changing the destination MAC address to the current MAC address does
not ensure that the packet will be looped back by the NIC.
If you change the destination of an IP packet in the outbound path of the
NDIS adapter ‘stack’, you are now responsible for performing the same set of
operations that the IP stack forward & ARP layers did when it decided to
send the packet on that adapter in the first place. You must:
- Resolve the destination IP address to an interface & ‘next hop’ address
by looking at the (or a) route table. - Resolve the ‘next hop’ address to a MAC address on the interface. This
could require an ARP exchange. - Possibly fragment the packet to match the MTU of the selected interface.
- Set the destination MAC address of the L2 packet to the resolved MAC
address for the next hop. - Set the source MAC address to the interface current address.
- Send the packet on the selected interface.
Now when operating as an IM driver ‘in the middle’ of all of this, it means
that for the general case you must be able to move an outbound packet from
one interface to another.
In your particular case where the new destination address is always an
address on the local host (the proxy) your problem is that you must reverse
the direction of the packet from an outbound to an inbound (receive) packet.
Moreover (and this is not true of NT5 but is true of NT6) you must be
prepared to lookup the correct ‘inbound’ interface and move the packet to
that interface. The IP stack may reject packets that arrive for an IP
address on the wrong interface in the strong host model.
Your approach of modifying the route table is flawed. You are placing a
host route into the route table and ‘covering over’ a host route that the IP
stack has already created. In the case of NT5 this is a ‘loopback’ route
->127.0.0.1 and the IP stack really does expect it to be there and
not played with. You are going to cause problems for other network
components if you attempt to modify how the route table and forwarder manage
loopback.
One thing that I think you may have overlooked is that when you edit the
packet, you must change both the source and destination addresses so that
the packet no longer appears to come from your local machine. In effect,
you need a ‘phantom’ address. Otherwise, when the local proxy sends packets
back to the sender, they will not return through NDIS at all but will take
the loopback path. This is why your work-around of whacking the loopback
route appears to ‘fix’ your problem.
To do this in an IM driver - which relies on the entire dialog passing on to
or off of the L2 link (no loopback), you must force the conditions of the
dialog to meet that requirement. In other words, you must make your ‘proxy’
appear off-host just like your original target machine that you are trying
to proxy to.
It would be far more straight forward to explain if you simply did what most
other proxy solutions do and that is one of:
1. Be a layered WSP and redirect to the proxy at the socket level.
2a [nt5]. Filter the TDI transport TCP (and/or UDP) and redirect at the TDI
level.
2b [nt6]. Filter via WFP mechanisms.
Good Luck,
Dave Cattley
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@freemail.hu
Sent: Thursday, November 19, 2009 4:42 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] NDIS redirect problem
Hello Experts,
We have an NDIS 5.1 driver which should redirect the outgoing http traffic
to a proxy server on the localhost. Our driver clones the packet and stores
it’s original source port (to redirect the answer backward). We modify the
destination IP, MAC and port parameters. If we do not modify the destination
MAC, the NDIS driver sends the packet to the network and some routers drops
it, so we have to modify it too. After then we regenerate the TCP and IP
checksums and forward the packet. We do the same for the incoming (answer)
packets. We can identify them from the port that we stored before.
This procedure works only if we modify the route and the arp table. So we
have to add the following lines:
route add [local.ip] mask 255.255.255.255 [local.ip] metric 1
arp -s [local.ip] [local.mac]
On XP machines this procedure works fine in most cases (only one machine had
problem, but it worked fine before too), but the Vista and 7 machines has
strange problem.
After a while the arp entry switches to invalid and disappears and then the
whole redirect procedure fails.
The only one XP machine does the same. It sends to the network the
gratuitous arp query and after then the arp entry disappears.
Any idea would be greatly appreciated!
Thank you in advance!
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Thank you for the quick and detailed answer!
We will have a look at the solutions you have recommended.