- This topic has 3 replies, 2 voices, and was last updated 19 years, 5 months ago by
.
-
Posts
-
Hello group,
I wrote a UDP-tunneling-protocol that sends all IP traffic UDP-encapsulated over just one single port. This was mainly neccessary because we want to send out DCOM traffic over just one port (instead of hundrets as MS defined it …) to make life easier for the firewall guys of our customers.
But we have also home-users who use the windows firewall. If we could say them “open port 1234 on your XP firewall” this would be great. But unfortunately the “windows packet filter kit” operates “outside” of the Windows XP (SP2) firewall:
APP — XP Firewall — PckFltKit (My tunnel) <~~~ INet ~~~> PckFltKit (My tunnel) — XP Firewall — APP
So the user must open a lot of ports in his firewall to let the complex de-tunneled traffic through. Is there any way to let the “windows packet filter kit” operate “inside” of the Windows firewall ? Because then the user would have to just open a single port to lett all tunneled traffic through …
APP — PckFltKit (My tunnel) — XP Firewall <~~~ INet ~~~> XP Firewall — PckFltKit (My tunnel) — APP
❓ ❓ ❓
Or is there any other idea ? Opening the WinWall dynamically for just one IP isn’t possible I guess. We dont want to tell the user “open 200 ports from 1100 to 1300 for the following .exe files: a.exe, b.exe, c.exe …” (By the way: DCOM sucks 🙂
Or is there another product as the “NT-Kernel-Resources windows packet filter kit” that operates “inside” of the firewall ?
Thanks a lot in advance 🙂
Roelof Berg
http://www.berg-solutions.de
(Question is for: http://www.bosch.de)Hello Roelof,
WinpkFilter drivers works on the bottom of the Windows network stack (below TCP/IP), but application layer of Windows XP firewall works on the top of network stack (otherwise it won’t be able to control applications network access). So I don’t think that there is any easy solution to this problem.
However, may be setting up the virtual network interface, disabling Windows firewall for it and bridging it to the real network interface using WinpkFilter can solve the problem. It’s just the first idea, may be some other tricks are also possible…
Hope it helps…
Interesing idea. Thanks. Bridging is on OSI layer 2 – maybe that is too low. I could also try routing instead of bridging (layer 3). But then I must activate ip forwarding which I don’t like due to security reasons.
I will give it (both) a try in a few wheeks after we released our application (because this is only “configuration” and not “programming”). Would be useful for my debugging too because I could let ethereal listen then “before” and “after” my tunneling application at the same time. That would be very cool 😀
Where can I get the “virtual network interface” you mentioned ? Is it part of windows ?
Thanks,
Roelof Berg
http://www.berg-solutions.de
(Question is for http://www.bosch.de)
- You must be logged in to reply to this topic.