Forum Replies Created
-
Posts
-
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. Я бы еще перегрузил систему на всякий случай.
P.P.S. If you plan UDP spoofing on the network interface using large amounts of packets then it also may have sense to create a special WinpkFilter driver build with larger amount of packets buffers.
P.S. You can also try PackThru sample which reads/writes blocks of packets from/to the driver and thus faster processes the queue.
WinpkFilter driver by default has 500 buffers for queing packets. When you send a large amount of packets on the network interface which is in the tunnel mode then driver internal queue is overloaded and network will be frozen until your user mode application process all these packets. So the reason is the application which does not process packets fast enough. May be it just does get enough CPU time. Try to assign packet filtering application a higher priority than your UDP sending application has. However, I don’t think that your network is really frozen, you rather expirience a huge packet drops because of massive UDP spoofing and this causes TCP resends and etc…
I can’t see if your filter application really does anything except console output. However, please note that console output is relatively slow thing and if you call it for every packet this cause a serious delay for each packet processing, thus causing slower reading packets from the queue. May be this was a problem in you case, however, I have not been expecting your code thoroughly. Why you just don’t use the tha passthru sample instead compiled with no console output?
Ну это не так как я советовал, судя по тому сколько в коде изменилось…
Вообще, если что-то не работает или работает не так как ожидается, я бы поставил сниффер типа Network Monitor и начал разбираться, с тем какие пакеты куда и как ходят. Сделать нормальный редирект в четыре строчки не получится, могу сразу сказать. Можете посмотреть пример NAT в Internet Gateway, это почти то же самое по работе с пакетами, просто задача другая. А разбираться с чужим неработающим кодом занятие неблагодарное, ну если, конечно, не за отдельные деньги 8)
Я Дельфи не очень читаю, поэтому лучше расскажу как это надо было делать.
Если собираешься фильтровать на внешнем интерфейсе и меняешь destination IP, то нужно запомнить какое соединение и как ты изменил (source IP/port, original destination IP/port). Иначе пакет с измененным (TCP SYSN) IP адресом выйдет наружу, удаленный сервер (на который был осуществлен редирект) тебе ответит(TCP ACK), а затем в полученном от этого сервера на внешний интерфейс пакете нужно будет заменить source IP/port (они на момент получения принадлежат серверу на который был осуществлен редирект) на те которые были изначально (куда собственно клиент стучался). Ну и так далее для всех последующих пакетов. У тебя же в коде всего одна проверка на адрес, и такой логики судя по всему не присутствует.
Хотя обычно такая фильтрация делается на внутреннем интерфейсе с редиректом на локальный HTTP сервер. Так как то правильней чем редиректить с внешнего куда-то на удаленный сервер.
