PSTATIC_FILTER_TABLE blocks DNS traffic

Home Forums Discussions Support Portal PSTATIC_FILTER_TABLE blocks DNS traffic

This topic contains 9 replies, has 4 voices, and was last updated by  nat32support 3 years, 4 months ago.

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
    Posts
  • #5391

    selim_ro
    Participant

    Hello, I might be using it wrong, but I am trying to block incoming http traffic coming from an internal network, that is not going through the proxy. The application is deployed on the gateway. To do this I’ve added 3 rules in the static filter table:

    the first filter:


    STATIC_FILTER filter = {0};
    result.m_Adapter.QuadPart = deviceHandle;
    filter.m_dwDirectionFlags = PACKET_FLAG_ON_RECEIVE;
    filter.m_FilterAction = FILTER_PACKET_REDIRECT;
    filter.m_ValidFields = filter.m_ValidFields | NETWORK_LAYER_VALID;
    filter.m_NetworkFilter.m_dwUnionSelector = IPV4;
    filter.m_NetworkFilter.m_IPv4.m_ValidFields = IP_V4_FILTER_PROTOCOL | IP_V4_FILTER_DEST_ADDRESS;
    filter.m_NetworkFilter.m_IPv4.m_Protocol = static_cast(packetFilter.netFilter.protocol);
    in_addr startAddress = IpStringUtils::ToIpv4AddressStruct(addressRange.startAddress);//proxy address
    in_addr endAddress = IpStringUtils::ToIpv4AddressStruct(addressRange.endAddress);//proxy address

    filter.m_NetworkFilter.m_IPv4.m_DestAddress.m_AddressType = IP_RANGE_V4_TYPE;
    filter.m_NetworkFilter.m_IPv4.m_DestAddress.m_IpRange.m_StartIp = startAddress.S_un.S_addr;
    filter.m_NetworkFilter.m_IPv4.m_DestAddress.m_IpRange.m_EndIp = endAddress.S_un.S_addr;

    filter.m_ValidFields = filter.m_ValidFields | TRANSPORT_LAYER_VALID;
    filter.m_TransportFilter.m_dwUnionSelector = TCPUDP;
    filter.m_TransportFilter.m_TcpUdp.m_ValidFields = TCPUDP_DEST_PORT;
    filter.m_TransportFilter.m_TcpUdp.m_DestPort.m_StartRange = packetFilter.transportFilter.portRange.startPort;//port 8080
    filter.m_TransportFilter.m_TcpUdp.m_DestPort.m_EndRange = packetFilter.transportFilter.portRange.endPort;//port 8080

    the second filter:


    STATIC_FILTER result = {0};
    result.m_Adapter.QuadPart = deviceHandle;
    result.m_ValidFields = TRANSPORT_LAYER_VALID;
    result.m_FilterAction = FILTER_PACKET_DROP;
    result.m_dwDirectionFlags = PACKET_FLAG_ON_RECEIVE;

    result.m_TransportFilter.m_dwUnionSelector = TCPUDP;
    result.m_TransportFilter.m_TcpUdp.m_DestPort.m_StartRange = 80;
    result.m_TransportFilter.m_TcpUdp.m_DestPort.m_StartRange = 80;

    the third filter:


    STATIC_FILTER result = {0};
    result.m_Adapter.QuadPart = 0;
    result.m_ValidFields = 0;
    result.m_FilterAction = FILTER_PACKET_PASS;
    result.m_dwDirectionFlags = PACKET_FLAG_ON_SEND | PACKET_FLAG_ON_RECEIVE;

    The problem is that if the DNS server is within the internal network, this configuration blocks DNS responses that are coming from the DNS server. The dns packets should only be matching the last filter, but they seem to be blocked by the second one. As a temporary fix I’ve added an extra rule before the second one, to allow all incoming traffic on that interface, that has source port 53. Is this a bug, or am I using the filtering table incorrectly?

    #7128

    Vadim Smirnov
    Moderator

    I don’t have the filters code under hand at the moment but for the second filter I would add that it should be applied to TCP protocol.

    #7129

    selim_ro
    Participant

    so… the new filters are:

    filter1: the same as in the previous post

    filter2:


    STATIC_FILTER result = {0};
    result.m_Adapter.QuadPart = deviceHandle;
    result.m_ValidFields = NETWORK_LAYER_VALID | TRANSPORT_LAYER_VALID;
    result.m_FilterAction = FILTER_PACKET_DROP;
    result.m_dwDirectionFlags = PACKET_FLAG_ON_RECEIVE;

    result.m_NetworkFilter.m_dwUnionSelector = IPV4;
    result.m_NetworkFilter.m_IPv4.m_ValidFields = IP_V4_FILTER_PROTOCOL;
    result.m_NetworkFilter.m_IPv4.m_Protocol = IPPROTO_TCP;

    result.m_TransportFilter.m_dwUnionSelector = TCPUDP;
    result.m_TransportFilter.m_TcpUdp.m_ValidFields = TCPUDP_DEST_PORT;
    result.m_TransportFilter.m_TcpUdp.m_DestPort.m_StartRange = 80;
    result.m_TransportFilter.m_TcpUdp.m_DestPort.m_StartRange = 80;

    filter3:


    STATIC_FILTER result = {0};
    result.m_Adapter.QuadPart = 0;
    result.m_ValidFields = NETWORK_LAYER_VALID | TRANSPORT_LAYER_VALID;
    result.m_FilterAction = FILTER_PACKET_PASS;
    result.m_dwDirectionFlags = PACKET_FLAG_ON_RECEIVE;

    result.m_NetworkFilter.m_dwUnionSelector = IPV4;
    result.m_NetworkFilter.m_IPv4.m_ValidFields = IP_V4_FILTER_PROTOCOL;
    result.m_NetworkFilter.m_IPv4.m_Protocol = IPPROTO_UDP;

    result.m_TransportFilter.m_dwUnionSelector = TCPUDP;
    result.m_TransportFilter.m_TcpUdp.m_ValidFields = TCPUDP_SRC_PORT;
    result.m_TransportFilter.m_TcpUdp.m_SourcePort.m_StartRange = 53;
    result.m_TransportFilter.m_TcpUdp.m_SourcePort.m_EndRange = 53;

    filter4: is the default filter, everything passes, the problem now is that the normal http traffic going through port 80 is not blocked

    #7127

    Vadim Smirnov
    Moderator

    From what I can see filter 2 is supposed to block incoming packets on local port 80. If this is what you want to do and still incoming packets on port port 80 are not blocked then there is only one possibility – these packets are passed by filter 1.

    #7130

    selim_ro
    Participant

    So I’ve remade the static filters, there seemed to be a problem with the way I configured the static filter that should have been blocking the local port 80, for now it seems to be working fine. However, the original problem is persisting, I have to add a special rule for allowing DNS traffic coming towards my machine. Even though there is no rule blocking it.

    #7131

    Vadim Smirnov
    Moderator

    To resolve an issue with DNS you can change all your filters from blocking to redirect and check filter ID in the DNS packets. So you can identify filter which selects DNS packets.

    #7132

    gmt
    Participant

    Hi, I am one of the “guys” involved in the original issue described here. One of the problems why dns traffic was being affected (blocked) was because we tried adding first some blocking rules that were supposed to affect only a certain types of traffic (say it only tcp or udp) but the FILTER_TABLE filters were not configured corectly for tcp/udp (they were catching other non tcp/udp protocols – arp… etc.)

    #7133

    Vadim Smirnov
    Moderator

    Thank you for the update. I’m glad that you have resolved the issue.

    #7134

    nat32support
    Participant

    @SerpentFly wrote:

    To resolve an issue with DNS you can change all your filters from blocking to redirect and check filter ID in the DNS packets. So you can identify filter which selects DNS packets.

    What is the “filter ID” and where is it to be found?

    #7135

    nat32support
    Participant

    @nat32support wrote:

    @SerpentFly wrote:

    To resolve an issue with DNS you can change all your filters from blocking to redirect and check filter ID in the DNS packets. So you can identify filter which selects DNS packets.

    What is the “filter ID” and where is it to be found?

    There is a variable called m_FilterID in structure INTERMEDIATE_BUFFER, but only in WinPkFilter 3.1.2 (and possibly later versions).

    I had been using WinPkFilter 3.1.1, and it did not have such a variable.

Viewing 10 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic.