Need design help - What rule importing sequence is best, etc.

So here are some questions to ensure I understand things better..

1) When you do the adapter releasing & renewing, you always see the “contact your DHCP server” message?
- a) If you always get “contact your DHCP server”, but now with 008.3 release you always remain with Internet connectivity?

- b) If you disable ‘Internet Filtering’ and run the adapter releasing & renewing, do you continue to see the “contact your DHCP server” message?

2) On the Look 'n’ Stop 'Log’ screen / Tab, do you always see DHCP packets being logged and blocked by 'Block : All other packets’ when doing the adapter releasing & renewing with 008.3 release?

 

To try to answer, I enabled logging of DHCP, ICMP, ARP rules so maybe that'll clarify a bit. Everything behaves as was yesterday in my post#21 - the two step, delayed, renew. And 008.3 of course.

Do you mean App svchost by UDP out to 67? I assume that's what you mean.

assuming my answer to 1) is correct, no issues that I can see. Another box is in the picture, and I moved the kerio shot over, as is Wilders on and off and while I'm writing this novel.

assuming my answer to 1) is correct, looks like I do - UDP broadcast

Running with Internet Filtering ON, so far YES. I din't check too carefully but I think they match the 008.2 ingressPNet bocks.

Screen shots for 1), 1a and 2) - Internet filtering ON.
I looked into the fields of the DHCP RSP rule. In field3 is a broadcast IP that looks like it might be for IPv6 (255.255.255.255.255.255). Perhaps when that initial renew fails, LnS or Windows decides to treat it as IPv4 and that's where I get the IP after all I don't understand any of this raw rule stuff, so this is just wild speculation. Also does do the DHCP allow in and out? Is the rule always 67 to remote 68 (as in Kerio) or 67-68 to remote 67-68 (as in Outpost)?
Lns log - I had to talk to myself there

There's one really weird packet U+62 in here.

I never see any blocking on another XP box in Kerio when I did release, renew today (logging DHCP and ICMP stuff and Block All of course).


Screen shot for 1b - Internet filtering OFF


These screen shots take a tremendous amount of space here. Would just submitting the logs be better? Raw Log?
Also, there is another raw log, though I think not on 008.3 - it has nothing but hex in it. What's it's use?

 

I’m understanding now, so the Build 008.3 does address the connectivity issue, and staying connected and connecting to the Router configuration page and pinging it also.

The problem I see, and I was confused because I thought you was saying that you was manually releasing AND then renewing the adapter via IPCONFIG (IPCONFIG /release ... IPCONFIG /renew). I was able to reproduce your experiences by simply skipping the releasing of the adapter and jump to renewing the already existing session. Waiting period after entering the renew command, and then followed by the error message “An error occurred while renewing interface Local Area Connection : unable to contact your DHCP server. Request has timed out.”.

So now we looking at the importance level for correcting this, I’ve always used IPCONFIG /release AND then IPCONFIG /renew, and never any problems. Also the regular automatic DHCP renew intervals isn’t affected, so you wont be on the Internet for awhile and all of the sudden you are disconnected because the DHCP packets was blocked.

 

I don't think you were confused. That's exactly what I was doing: ipconfig/relese, wait a tad, ipconfig/renew.

I'll watch for disconnects. and report back if happens. I forgot that's possible, and saw it only years ago when, in ZA, DNS servers weren't trusted. Unless it disconnects, the importance level of these blocks is close to zero

Also resume from standby uses DHCP - so far so good.

Incidentally, all those blocks, when I look at them are identical. Even the visible hex part.

 

Must be the different versions of IPCONFIG utility or different Windows with modifications to the Networking.

If you compared the source and destination IP addresses with DHCP Request / Response packets when it does it automatically and not being blocked, to source and destination IP addresses with DHCP Request / Response packets when doing manual adapter releasing and renewing (or in my case only when renewing the already existing session and skipping the release part), you’ll see there is a change.

 

Well DNS packets are important, if you don’t allow, connecting to sites via hostname would fail unless already been recently cached.

If the DHCP packets are blocked, you’ll fail to connect, if you get connected but later when the DHCP is about to expire and needing to renew, and these packets are blocked, you won’t beable to connect to anything until the DHCP packets are permitted.

Anyways, If you e-mail me, or PM me and include the attached DHCP Req/Resp rules or importable rules file with both rules included, I can make the quick adjustments to permit the manual adapter renewal. .

 

I understand that since the ZA days.

So I did few experiments out of curiosity. I told the router to give me a 10min lease so I could watch automatic renewals.
- While I was doing nothing, it was doing all those ARPs and blocks as yesterday, and was renewing with hiccups, just like yesterday. Under both, wired and wireless scenarios.
- Then, wired, still with a 10min lease, I logged into Wilders and did nothing, doing other things. It was doing its blocks and renewals, during which, obviously, connection was being lost and rescued once the packets got permission to come in after that hiccup. I suppose an impact on something like streaming news or music would not be pleasant, but as far as browsing=Wilders, during all that, was still ok. Did I learn anything? Maybe

I'd like to, thanks a bunch. The only thing that scares me is the if new P-rules come out, will I be able to use what you plan to send?
Also, "importable rules" means to Export the 2 DHCP rules to .RIE file, correct? Any logs you need?

Possible LnS 2.07 bug:
The other day I was exporting a rule, was careless about the destination path LnS remembered but I forgot that earlier I moved it, so it wasn't there, and LnS crashed badly. No cancel, no OK, no window X could close it. Tried killing via Process explorer also failed. But using PE logout was sufficient to not have use the Power button. Implication - make sure the destination directory exists.

 

You the first person to experience problems with the SPI DHCP rules, I guess it might be a faulty Router or Internet modem?!? heh

Correct, simply export the two SPI DHCP rules to .rie file, no logs needed, you already provided everything on this topic. The change is swift and secure and all you need to-do when you get the updated importable rules file is delete the already existing SPI DHCP rules and import these and relocate to the original SPI DHCP rules positions.

 

No modem. FIOS in the wall
No ISP software. Ditched ISP's router. Using this trusty old thing:

Faulty router ?!?!?!
Ha!
Very picky, cool, firewall?

 

The original firmware replaced ... this hyperwrt firmware might be buggy? heh

Well a rule of rule-based software firewalls.., they only as good as the set of instructions ;p

Just unusual experiences you reporting, I’ve understood connectivity issue when the Ingress filters wasn’t adjusted in such a setup like yours, but that being addressed in Build 008.3.

Well the e-mail with the updated SPI DHCP rules been sent, this should correct your secondary DHCP problem.

 

OMG, Phant0m, I was sure I thanked you for the new DHCP rules. Apologies for the delay! THANK YOU. Feedback - good and not so good news.

(1) At home, behind a router, everything works great. Wireless - everything is fine.. Also at home, direct connection to ISP, no routers, everything works great. Connections are maintained no matter what I do or don't. Pings work. Release-Renew still is a double step process where only after getting the 169 deadIP the responses from out there aren't blocked. But how often one does release-renew? Small annoyance, not worth fixing. Except ...

(2) I ventured out to the library with its unsecured wireless connection. Under the enhanced rules, I got the IP and all that. Installed 008.3 ruleset. I did not import new DHCP rules because I think they are specific to my router. I wasn't on the internet, just watching things. Little did I know, the gateway pings and drops you for non activity = no replies to ping. Even with their 24hr lease. Since I wasn't logging or dinging ICMPs I din't know I was doomed. Anyway, connection lost, I got 169.x.x.x IP. I tried waiting to recover, then release-renew. No go. 'Cause I continue blocking their responses. I had to reboot, then got on the internet and stopped the experiments. Rawlog attached. Lots of trash in there, so I wrote up top what happened when and some IDs.
View attachment raw08052011.log

 

Hi,

I’m a bit swamped for the moment, but I do have time for question #1.

You have two types of connections, perhaps dead-IP is coming from the other adapter, when you are manually renewing using the general command, it is trying all adapters. So I purpose you use ipconfig /renew *Local* for wired adapter, and ipconfig /new *Wireless* for wireless adapter.

Other things you can try also when troubleshooting, disable the Internet Filtering layer and run your test, problem persists then disable Application filtering layer, then DLL & Protocol filtering and re-test.


Regarding question #2, to partially answer, the importable DHCP rules was designed for your home Internet, or Internet using the same DHCP server IP address ...
....
... having just looked at your log file that you was generous enough to share publicly, I see your main problem is again with the DHCP boot replies skipping right through the SPI DHCP reply rule and straight to the block all rule. And don’t take me the wrong way, I value each and every customer of mine, but I never seen any user report previously made regarding problems with the SPI DHCP reply rule. Now you are experiencing this on two different Internets, with that one computer, makes me wonder...

Anyways, the updated SPI DHCP rules that I had sent you (if updated to replace the existing DHCP server IP information with the new one) will work for that other Internet. I’m planning on updating the P. Ruleset Installer to use the new changes I made with the SPI DHCP rules that are already done in the manual set I had sent you already. ... Even though you the only one thus far to encounter this type of problem with automatic DHCP renew intervals, and even with the manual network adapter renewal (even skipping the releasing part), and I’m only able to reproduce this when skipping the manual release step and just running ipconfig utility using the /renew parameter.

The other problem, the one you experienced on that other Internet, with Ingress rule, that isn’t much, a minor update on-top of the current improvement for Ingress rule configuring.

I’ll update soon as possible, right now I’m with several tasks I need to finish up today, but I’ll anyway report back when having released the new update.

And thank you.

 

1. Re: two adapters. Interesting thought about maybe 169 applies to the "other adapter". I don't think it works that way.
Right now, I'm wired. Wireless is off. So I try to renew wireless, but the screen complains "The operation failed as no adapter is in the state permissible for this operation."
ipconfig /all - no dead IP here, it still says "Media disconnected". It'll be the same when wired is off, and wireless on.

2. Re: try without filtering, then apps, then dll - Without filtering we already did under 008.2. I can repeat if you wish.
Apps and Dll I could do at home, but that library place is not safe. Unless I image again(5min), do it, restore again (25min), yikes. I'll do it if you insist, but it's scary. I have to think about it.
Though I don't see anything in the log to be concerned with, not even one TCP or UDP that's other than the renewals (ignoring all that ARPing)

3. ipconfig /renew alone behaves differently than release-renew. I also like both 'cause it tells me how a new firewall will be at bootup, starting with the zero octet. Renew alone doesn't (or so I think) tell me that. I once read something about it in some M$ publication where they explained the difference.

4. No rush on my account please. Time is money. Time belongs to you. Time is for fun and rest. Do only if you have time and feel like it. I'm having a bit of fun learning this stuff What do I need the library for when I can do it all at home! (Family, if fails, might be a small issue)

I just read the title of this thread "What rule importing sequence is best", hmmmm

 

Regarding #4, ... I wasn’t getting any rest yesterday, nor was I having much fun. I managed to get things situated by midnight, so since I’ve been up that long, I decided to simply dive right into updating the P. Ruleset. I’ve updated the SPI DHCP rules, so now you shouldn’t need to import those DHCP rules that I had done up and sent via e-mail. I also tweaked my previous enhancement to that Ingress rule configuring, now that should be finally good for whatever Internet you install P. Ruleset for.

I’ll get to your other questions later on in the day, I also included some additional good surprises, I’ll detail them later in the day, at the original ‘Changelog’ area, in the meantime the new P. release is available for grabs.

 

008.4 Thank you.
If bill Gates was as fast as you, life would be wonderful
I had to import ARP rule from 008.3, otherwise ping the router failed.
At home, release-renew looks a bit different, services is now logging, didn't before (!! was in 008.3 all along and never logged a thing).
Various blocks still occur but might be totally normal for WinXP. Renew alone is also ok.
If you need the log, holler.
I'll try some wild place as soon as I can.

 

No problem act8192, and thank you.

Are you certain the ARP rule you in reference to? Because the same ARP rule still exists in 008.4 or do you simply mean the ICMP rule for echo requests?

Various blocks is normal, but as long as your Internet and the Internet-based applications that you run is working as normal. You can however send me the log file and I will take a gander at it, just to make sure... sorry, I don’t think it’s polite to holler at the hands that feeds me.

 

Arrgghh!
From the log: "U,0,53,'Block : All other packets',0806,42,FF:FF:FF:FF:FF:FF,00:0F:B0:55:90:55,192.168.54.54, 00:00:00:00:00:00"
Yes, the 008.4 has ARP, right on top, a new position.
How I messed up I don't know, it happened sometime after I imported few of my rules. Perhaps I deleted something by mistake.
I just reloaded your original rules, added mine, all is well. Sorry for the false alarm.

Phant0m, I could use more advice, because I don't have a clear workflow in my head yet:
(1) with that traveller flag set in the .ini file, do I still need to load enhanced and then P-rules when I go outside the home and deal with multiple configuration files, or can I just use what I now have and hope it works?
(2) Traveller flag is in the wireless .ini section. What if I connect to family's router using the cable instead of radio? They allow me to do that.

 

* LOL!! I’ll overlook your mistake just this once...

1) Having installed P. Ruleset using the Traveler ForceConfig.ini flag set, no need to be loading first the pre-packaged official Enhanced ruleset, loading the Enhanced Ruleset is only when you installing P. Ruleset for a new Internet. Traveler support doesn’t restrict rules based solely on the specific user or place connection type, so when having installed P. Ruleset with Traveler flag set, no need to be switching over to Enhanced ruleset.

2) That is actually my mistake, I added sections recently to the ForceConfig.ini to help users a little better when glancing for the first time in the ForceConfig.ini file. Even though the Traveler flag is under Wireless section, it’ll still work for Wired connections too. I’ll make a new section in the ForceConfig.ini for this Traveler flag, for the next release I make. Sorry for the confusion!

 

(1) 008.4 feedback from using unsecured network and wireless connection
a. Disconnect and connect back is very fast
b. Standby and resume works fine
c. pings of gateway which occur as I go to Wilders was logged as tracert, which is ok because TTL was 1
d. release/renew no change - required reboot or what I did this time was make a rule to allow the DHCP on their DHCP server. As soon as made a rule, I got IP. The rule is up top, where should it go? (we're on topic now)

(2) Is the Networking flag in the .ini file for anywhere or my LAN? It's currently zero.
I ask, because of this thread https://www.wilderssecurity.com/showthread.php?t=305038
I was going to do some pinging from one of my boxes, and it was all blocked by SPF ICMP rules, makes sense, unsolicited and the dumb computer can't read my mind that I wanted it. I hate computers.
I use XP, the thread is about Win7, still, I have seen the behavior Stem reports (resume from standby, also at login) in Outpost v7, so was going to take a peek what happens in LnS, but failed experimenting.
At this point I just added my own ICMP rules, up top, ignoring the SPF rules (maybe), and that allow pings in. Where should I put my rules? - this is finally on topic

 

Hi,

Regarding d), was this under Traveler mode? or P. Ruleset installed under the regular mode?

2) Please visit the sticky regarding ForceConfig.ini, found on the other board. Not sure I’m following regarding your purpose to allow ICMP ping requests in, but to reproduce Stem results, it is better anyway to keep ICMP Echo requests coming in .. blocked, and pinging is re-occurring for at least two minutes in after awakening from sleep mode, and repeating .. this ensures quality test being performed.

 

Hi Phantom,
d) 008.4 installation was with traveller=1

2) ok. I get what you're saying regarding the test.

I just read the .ini sticky and finally understand a bit more. I will reinstall P-rules with that Networking flag and IP range set for my LAN. Might be, then, able to eliminate few rules I had to add for these boxes to chat. The thread in that sticky also has NetSel=1 suggestion. Do anything here? There is no such in the .ini file currently.

So this Networking=1 is a similar thing to "trusted network" in other firewalls?
I assume (hope) that filesharing activities will be permitted only in the IP range specified in the the .ini file, and no other, correct?
Do I need to include all the way to 192.168.x.255 for broadcasts? My printer needs it.

 

Hi,

Regarding 1) d., we talking about at “some wild place” right? I'll need the log file to troubleshoot.

NetSel was replaced with NetIPRange, usage information detailed on the original post. “If you only have a small handful of network computers, perhaps you prefer to restrict using IP range. NetIPRange (Deluxe feature) will allow you to specify a range (example: a.b.c.100 - a.b.c.150). By default this support is disabled, to enable this, remove the line REM ‘ ; ‘, when enabled this feature will over rule the SubnetMask feature. By default NetIPRange is set for range a.b.c.100-110.”

Networking=1 activates networking only for the supplied settings, and the networking rules already supports broadcasts, it is required.

 

Re 1d) Phantom, your patience is amazing. Yes, wild place - see post#44.
Log and screenshots in the mail.

NetRange - I used this syntax a.b.c.100 - a.b.c.150. I left subnet there and removed ;comment.
Thanks for explaining.

 

E-mail received, I’ve sent you a temporary importable rule to use for the Traveler set until my next release.

 

It works like a charm. Everything is fine, at home and in two wild places. Thank you!