CHX-I 3.0 users

I have wan_start ruleset, imported both times to

1. Packet Filters (global)

2. Local Area Connection.

When I tried to add TCP, UDI, and ICMP SPI protection from the properties interface of Local Area Connection, I can't connect to the Internet. Sometimes, CHX-I logs me out of my ISP service: 192.168.0.1.

I use AT&T DSL home service that gets a dynamic new ip address each time through DHCP.

 

Hi:

I'm using CHX 3.0 behind a router without any special network rules
beyond the wan_start set, and it works fine. However I'm not a
networking expert, so am not qualified to offer you help with your
problem. Take a look at the following thread and see if it gives you
any clues:

https://www.wilderssecurity.com/showthread.php?t=124457

I believe they are dealing with version 2.8 in that thread.

Hopefully, someone with the proper skills will see your question,
and help solve the problem.

 

What did you mean by "both" times? wan_start needs to be imported only once - on the NIC. It is to be used with the stateful inspection enabled.

 

Hi RootAccess,

As mentioned by Seer, you only need to import the rules to the NIC/Interface. Then the rules will apply even if the IP changes.

If you do still have problems, then please post the logs, these will show what as been blocked, so we can then help.

 

I looked at the logs and this may be the cause of it.

My modem address is 192.168.0.1. Everytime I log on to internet, I get another a different ip addresss assigned by AT&T. Because the ip address no longer matches, CHX-I blocks the connection. How do I prevent this behavior from happening?

 

Here is the log:

removed log,... privacy/ security, stem

 

Have you tried Stem's advice and only putting the rules on your NIC?

 

Hi RootAccess,

Your log shows many inbound connections being blocked/dropped. I presume you are using torrent/P2P?

I am first removing your log, due to that showing your IP/MAC (members here will understand that)

To allow inbound for torrent/P2P you will need to apply a force_allow_rule on the port you are using (which from your logs would be port 53750)

The latter part (end) of the log does show that DHCP is being blocked, so that could cause problems.

 

No P2P. Why is DHCP blocked?

When I turn off SPI, I can log on fine. However, if I can't use SPI, I won't be using CHX-I in the first place.

 

Your logs show many attempts for inbound, it could be down to others using that IP before you. Are you on a shared LAN.

It is being seen as unsolicited, so there are no rules to allow. You may need to force_allow such for DHCP.

It can be confusing with rule creation at first, stay with it, we will sort out any problems together.

 

There's a force allow DHCP rule that's included with wan_start. I change the ip address to my modem's address but still no connection.

I'm not on a LAN.

WSFuser, yes to your questions.

 

RootAccess - did you already try using the DHCP rule without modifying it?

 

There is problem with DHCP, the end of log show the possible problem (I can show that without user compromise)

 

RootAccess,

You appear to be on a large LAN. As your gateway has the IP of x.x.0.1 and your own IP is x.x.1.64, your subnet mask should be 255.255.254.0 instead of default one in DHCP rule.

 

It is probably the DHCP NACK/ACK during renewal/ rebind.

CHX-I ignores this particular instance - a DHCP force allow incoming (UDP rule) would solve this, with srcIP=192.168.0.1 and dstIP=any and dstPort=68

Cheers,

Stefan.

 

RootAccess posted stating the use of the wan_start ruleset, that ruleset does include the force_allow for DHCP.

 

If I remember correctly - the rule had the ff-ff-ff-ff as a destination. I suggested changing that to Any to avoid this particular shortcoming.

Regards,

Stefan

 

wow, Stefan himself is here again!!!

Any news about the future of CHX-I?

 

Well...I do lurk around in forums - old habits die hard...

As for CHX-I, I am somewhat surprised it is still being used after all these years. That is a very bad practice from a security perspective (running discontinued software).

I cannot comment on the present, nor the future - but I can tell you I have always enjoyed and respected any form of discussion around security, especially when it involved CHX-I.

Best Regards,

Stefan

 

As long as Windows XP is here and am not using IPv6, i'll continue using CHX-I as an alternative to XP SP2 Firewall (am not a fan of leaktest).

You've really done a great job with CHX-I! Thanks!

 

The new rule suggested by Stef_R is working out for me. Thank you so much. Just to make sure:

1. I have imported wan_start to only the Local Area Connection.

2. The new rule is made by clicking on new filter. When defining the source port there are four options: Any ; Masked IP ; Range ; Define IP list.

I chose Masked IP and put 192.168.0.1 both times to IP and Mask boxes. Is that the right way to do it? The other part of your rule is pretty clear to me.

Oh by the way, I re-downloaded wan_start from WsFuser and notice he added the deny ingress rule. What is that about? Do I need to do something about it? I read other people have tinkered with it before but not sure why they did.

 

CHX-I provides strong protection and is free. I like using softwares that are the cream of the crop. If you ever have any computer security recommendations, I sure would like to hear it. I'll be happy to share my security set up with you in private if you like.

 

I believe, the Deny Ingress filters is no longer necessary with CHX-I 3.0, with SPI on..

 

Could someone please tell me the reason why IPv4 minimum combined header length should be 120。

 

120 is actually the maximum combined header length (IP + TCP): the IHL field of the IP header allows for a maximum of 4 bits, that is 0xf x 4 = 60, and it is similar for the TCP header. In normal circumstances the minimum MTU doesn't go below 500, so there is no reason to break packets into fragments smaller than 500 (except the last one), especially the first fragment. Dropping the first fragment smaller than the maximum combined header length is CHX's way of dealing with a possible "tiny fragment attack".