Forum Replies Created
-
Posts
-
Most probably this is VMWare bridge, in order to support bridging of guest OS it has to put real network interface into promiscuous mode and has to filter out loopback indications. Since packets are repackaged by WinpkFilter it may miss to recognize loopback and reroute it. I have experienced similar problems when experimented with ethernet bridging. There is another post on forum regarding VMWare, so I plan to do some tests with it. By the way, do you experience any problems in getting IP address for the guest vmware OS bridged to real NIC?
From what I can see each outgoing echo request is looped four times. Probably this caused by loopback packet indication when outgoing packet sent from one protocol is indicated back to all installed protocols (without this functionality wireshark would not be able to collect outgoing packets). And in your test loopback packet is routed back into the network (note the decreased ttl). Difficult to say who has routed the packet as WinpkFilter does not implement routing but WinpkFilter repackages network packets and one of the installed network components may fail to recognize the packet it just sent out and rerouted it. What network components do you have installed? Here I mean protocols drivers like winpcap and various virtual machine bridge and NAT components? Details in the network configuration also may help.
I had not heard about such issues before, however I think it can be related to filter layering with VMWare bridging driver which is also probably implemented as NDIS LWF or NDIS IM driver. In order to support virtual network adapter with its own MAC address VMWare bridging driver probably puts real hardware NIC into promiscuous mode and clone received packets to virtual NIC inside VMWare. Here you probably have a sort of conflict between filter drivers, when packets for virtual NIC MAC address are not delivered to VMWare driver. Could you try uninstall VMWare, reboot and reinstall while keeping Winpkfilter installed? It may change drivers layering and fix the issue.
Could you provide more details in regards to network configuration. Who assigns IP address to your internet connected network adapter? By other words, is Internet network adapter connected directly to ISP or through the router/NAT wchich assigns IP addresses over DHCP? Does it changes anything if you manually assign an IP address to network adapter inside VNWare OS?
At the moment we don’t have plans to update DeviceFilter for Windows 7. Regretfully this requires serious research but market demand for such tools is too low to compensate the development efforts.
Yes, you have to recalculate checksums if modify the packet content. What code do you need? Checksum recalculation?
Probably the easiest way is resetting the TCP session which tries to fetch the image you would like to block. Manipulations with HTTP server responses is far more complex task.
Philip,
That depends on the functionality you expect from your captive portal. iGateway is a simple NAT solution. What problems have you expirienced with it?
Yes, this is possible using WinpkFilter. You can bridge VirtNet adapter to the real network with WinpkFilter or emulate virtual network with WinpkFilter. However, note that if you use bridging and want your real card to receive packets for the VirtNet card MAC address then your real card must be in promiscuos mode.
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 пакет. Это уже на выбор. Ну а так в общем должно работать.
