Closing current connections based on ip address?

Networking
21

Hi @slaterson

I may have read your comment a bit too optimistically but at the same time if you are willing to have a look at it and see if you can do something with it, that would be great. If you get to a point where you decide you can’t help with it then you can always step back from it.

I am also not a developer and all my coding is hobby based but I have learnt how to do things in perl with IPFire and have been able to successfully fix some bugs.

The IPFire team is a very small team and, as well as their day jobs, work on the major aspects of IPFire, such as the next generation IPFire-3.x, Security problems etc.

Currently in the IPFire Bugzilla, there are 432 open bugs, covering IPFIre, the Website, Infrastructure, Pakfire packaging manager, Location etc.

It is good to get your bug raised as it is then recorded and won’t get forgotten about, but it might take some time for someone to be able to work on it. There was a bug from last November on adding Base64 encoding to the PSK for use in IPSec and I said I would pick that up but I have only just now got the space to be able to start working on it.
That is why we are always happy for people to pick things up that they have personally found and experienced.

If you do decide to have a go at the bug and run into problems then you can always come to the forum for support and help.

Best of luck, whatever decision you end up making.

1 Like
22

i pulled ipfire 2 and 3 last night to poke around. i’m struggling to find where the timezone conversion to UTC is happening.

23

I am not sure any UTC conversion is done. From my searching it seems like it just uses the time on the basis of being your local time.

However I could be wrong.

I looked in firewall.cgi and found the section collecting the TIME_FROM time.
https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=html/cgi-bin/firewall.cgi;hb=16c1c5c6f83b8ccb4f6216519f4686cbfb7da676#l2113

I then looked for the

$selected{'TIME_FROM'}

variable in the same cgi file and found

$selected{'TIME_FROM'}{$fwdfwsettings{'TIME_FROM'}} = 'selected';

Then searched for

$fwdfwsettings{'TIME_FROM'}

in the same cgi file and found

https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=html/cgi-bin/firewall.cgi;hb=16c1c5c6f83b8ccb4f6216519f4686cbfb7da676#l1611

which links that variable with $hash{$key}[26] which by searching in IPFire generally I found to also be in the rules.pl file

https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=config/firewall/rules.pl;hb=16c1c5c6f83b8ccb4f6216519f4686cbfb7da676#l336

which, as far as I can tell, is where it then defines the --timestart and --timestop values which are used in the iptables rules.

The coding structure looks to be based on the --timestart and the --timestop both being in the same day.

Hopefully the above links and pointers will help you in terms of which part of the code to look at.

24

From Man page of iptables-extensions

I’ve checked rules.pl. The times are converted to UTC.
So you can specify time constraints in your time zone, the iptables rules use UTC.
Adding --contiguous should solve the problem. Didn’t find, if the option can be specified always.
Another problem to solve is the conversion of the weekday.
Mon 01:00 UTC+2 —> Sun 23:00 UTC.

2 Likes
25

adjusting the weekday is the first thought i had. if < then add a day to the weekday specified. i think this would work for timezones to the west of UTC (-), haven’t thought through timezones to the east of UTC (+).

26

It works for both directions.
If the conversion of starttime needs a correction add/subtract one day.
The computation in rules.pl is done roughly as follows

  • convert time hh:mm to minutes
  • compute the difference utcoffset=time-gmtime in minutes
  • time += utcoffset
  • if time<0 time += 1440
  • if time>=1440 time -= 1440
  • convert time to hh:mm

The correction can be used to change to week day mapping; time<0 means one day before ( Mon → Sun, … ), time>1440 means one day after ( Mon–>Tue, …).

Some “little” modifications should make it possible.