Forum Replies Created
-
Posts
-
If I understand you right you have two WAN connectons, need to distinguish them on packet level and match against the WAN link from the control panel?
In Windows multiply WAN connections can be established through NDISWANIP interface, on the packet level they can be distinguished my their MAC addresses. Regretfully, there is no strighforward way to match WAN link to the WAN connection name in the control panel. However, it can be done through quick packet analyses. You can get source IP address from the packet and match it against against the connection using IP helper/RAS API. Each WAN link has a single IP address assigned and it uniquly identifies the connection.
I don’t understand your question. You can use WinpkFilter to send packet to the real interface. VirtNet is just a simple dummy network inetrface with no real functionality. But in combination with WinpkFilter it can be used for building virtual networks.
Do you have any other protocols besides TCP/IP installed/enabled on systems where you expirience the duplicates? Packet duplication is related to protocol-miniport bindings (an example, when you run Wireshark you have one extra binding for winpcap protocol driver) and loopback packets indications (each outgoing packet from one protocol driver is indicated to every other bound protocol, each incoming packet is indicated to every installed protocol). I think in some cases a sort of mess up is possible especially if you use bridging drivers (which is actually protocol driver which works as packet repeater). If you uninstall WinpkFilter it is fully removed from the stack and plays no role in packet processing. So probaly duplicates caused by some other network components installed on your computer.
Usually duplicated packets are caused by bridging drivers. In your case it may be vmware network drivers.
Для такого редиректа можно использовать не loopback, а реальный локальный адрес. То есть скажем если компьютер A имеет сетевой интерфейс с IP адресом 192.168.1.2 и пытается соединиться скажем с 64.251.25.36:80, то мы можем поступить следующим образом:
1) Для исходящего от клиента TCP SYN пакета меняем адрес назначения с 64.251.25.36 на 192.168.1.2, порт назначения меняем на тот на котором висит SOCKS. Адрес источника заменяем на некий реально неиспользуемый в LAN fake адрес, например это может быть 10.0.0.10. Пересчитываем контрольные суммы и вместо того чтобы послать пакет в сеть посылаем его вверх по стеку.
2) SOCKS сервер отвечает нам пакетом ACK-SYN c адреса 192.168.1.2:SOCKSPORT на 10.0.0.10. Для этого пакета мы меняем источник на 64.251.25.36:80, назначение на 192.168.1.2 и снова после пересчета контрольных сумм вместо того чтобы отправить пакет в сеть посылаем его вверх по стеку.
3) Клиент нам отвечает пакетом TCP ACK с которым мы поступаем аналогично пункту 1.Проще всего совместить WinpkFilter редиректор в одном приложении с SOCKS сервером, проще будет понять куда какое соединение нужно реально направить.
Что касается части с редиректом, то ничего сложного нет. Видим исходящий TCP SYN пакет (попадающий под наш критерий, скажем идущий на HTTP порт 80) для этого пакета:
1) Аллокируем структуру в которой запоминаем данные для этой новой TCP сессии (адреса и порты).
2) Подменяем IP адрес назначения на адрес компьютера B, порт назначения на порт на котором слушает SOCKS.
3) Пересчитываем контрольные суммы пакета и отсылаем его в сеть.
4) Для пакета полученного от компьютера B проверяем принадлежит ли он одному из сохраненных в первом пункте.
5) Если да, то меняем адрес и порт порт источника на те что были в исходном TCP SYN пакете и посылаем вверх по стеку.Но все бы хорошо, но каким образом SOCKS узнает IP адрес и порт которому изначально направлялось соединение? Мы то их подменили при редиректе. Каким-то образом эту информацию нужно передать от компьютера A компьютеру B. Это можно сделать по дополнительному каналу или добавить дополнительные данные в TCP пакет. Это уже на выбор. Ну а так в общем должно работать.
Требуется что-то подобное http://www.ntkernel.com/w&p.php?id=36 ?
Is there any way of determining when the RAS_LINKS table is valid?
IP Helper API has addded certian new functions since Windows Vista which allows you to register callbacks on network interfaces changes. I think you can use these functions. An example, there is a callback on routing table changes and when new network connection appears in the system the routing table is definitely changed.
I’ll take a look at Xen as soon as I have time for this. Xen does not seem to be an easy thing to setup and configure. The behavoiur you have reported looks very strange. What WinpkFilter version have you installed on that system? Has the instalaltion went smooth? Network blocking may happen if driver is installed but not loaded (because of signature problems) in x64 Windows. Have you lost the connection immediatly after driver installation? Was you able to reconnect before rebooting? After the reboot? There is a chance that during the installation process the network was already blocked (driver started installing) but Windows still needed some sort of interactive confirmations from you, so the installation has not completed succesfully causing the network getting down.
Why you don’t provide option to bypass packets when the buffer is full?
This is done to prevent packets to bypass filtering. Most of WinpkFilter applications can’t afford passing unfiltered packets. However, this can be done in custom driver build.
Why you don’t provide WinPKFilter to close application capture event handle when it detect application does not response or does not process packets it specific time?
Same reasons as above. Application can be not getting CPU time for some period, but it does not mean that security has to be broken and filtering should be dropped. Filtering is turned off if and driver is reset to default state only if all user mode WinpkFilter clients are terminated.
Is WinPKFilter report it to a log file when such issue happen? How we can find the original reason of such issue?
I don’t see much sense in logging such an event as it does not really provide an information what has happened. Check your code for reading packets from the driver. This is the only way.
Please note that internally WinpkFilter driver uses a limited buffer pool used for all packet related operations. So, an example, if you set a network interface into the tunnel mode and won’t read filtered packets from the driver then the number of queued packets grows up to the buffer limit and as soon as the limit is reached the network operations are blocked for all network interfaces (network freeze). So if you expirience the network freeze it is more likely to be a bug in your application. There are many WinpkFilter based applications on the market, and if it would be a kind of hidden bug then you won’t be the only one who expirience this.
By the way, what kind of driver you have installed on your server? NDIS IM or NDIS LWF? Both drivers can be used on WIndows 7, but they are different by architecture. So if you try another one there could be a difference in behaviour. However, if this is application bug then most probably the behaviour would be just the same.
Hmm, looks strange, however I had not tested WinpkFilter in XEN VM before. SO several questions:
1) Do you have VLAN enabled interfaces in Windows 2008?
2) Can you check is RDP connection established but dropped or not even established (you can check this using network snifer)? If ping works but another protocol fails it can be MTU (packet size issue), as ICMP packets are very small by default.
3) Can be the system be accessed by any other protocol/port besides RDP?
4) Do you use any WinpkFilter application on the system or just the default driver installation stops the RDP?Возможно остался ключ в реестре HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservicesndisrd. Удалите и его тоже. По идее если драйвер деинтсталлирован, удалены кешированные INF и ключи реестра, то следов остаться не должно. После всех удалений желательно перезагрузить систему.
Возможно WinpkFilter устанавливался по разным путям, система запомнила первый и теперь не может найти драйвер. Я бы удалил драйвер стандартными средствами, а затем нашел бы INF файлы в папке Windows/INF которые содержат строку ndisrd. В случае с LWF нужно удалить пару файлов вида oemXXX.inf и oemXXX.pnf. Я бы еще перегрузил систему на всякий случай.
