Re: Question that has dogged me for a while.

Am 05.05.2017 um 21:14 schrieb Karl Denninger : > On 5/5/2017 19:08, Dr. Rolf Jansen wrote: >> Am 05.05.2017 um 20:53 schrieb Karl Denninger : >>> On 5/5/2017 14:33, Julian Elischer wrote: >>>> On 5/5/17 1:48 am, Dr. Rolf Jansen wrote: >>>>> Resolvi

Re: Question that has dogged me for a while.

Am 05.05.2017 um 20:53 schrieb Karl Denninger : > On 5/5/2017 14:33, Julian Elischer wrote: >> On 5/5/17 1:48 am, Dr. Rolf Jansen wrote: >>> Resolving this with ipfw/NAT may easily become quite complicated, if >>> not impossible if you want to run a stateful nat'tin

Re: Question that has dogged me for a while.

Resolving this with ipfw/NAT may easily become quite complicated, if not impossible if you want to run a stateful nat'ting firewall, which is usually the better choice. IMHO a DNS based solution is much more effective. On my gateway I have running the caching DNS resolver Unbound. Now let's as

Re: IPFW problem with passing IPSEC through in-kernel NAT

> Am 09.12.2016 um 02:11 schrieb Karl Denninger : > ... > Some more information on this issue I suspect that something is > getting mangled somewhere in the IP stack, perhaps related to hardware > checksumming or similar -- or in the ipfw code. I had always ran into IPsec-NAT-UDP checksumming

Re: Notice on upcoming ipdbtools 1.1.1

> Am 14.08.2016 um 12:15 schrieb Dr. Rolf Jansen : > > As was noticed by the port maintainer, the initial release of ipdbtools 1.1.0 > into the ports did not compile on i386 systems because the lack of the > __uint128_t data type on 32bit systems, and which was used for IPv6 com

Notice on upcoming ipdbtools 1.1.1

As was noticed by the port maintainer, the initial release of ipdbtools 1.1.0 into the ports did not compile on i386 systems because the lack of the __uint128_t data type on 32bit systems, and which was used for IPv6 computing. In the meantime, I rolled in the necessary uint128 comparison, shift

Re: your thoughts on a particualar ipfw action.

> Am 11.08.2016 um 14:20 schrieb Ian Smith : > On Thu, 11 Aug 2016 10:09:24 -0300, Dr. Rolf Jansen wrote: >>> Am 11.08.2016 um 08:06 schrieb Ian Smith : >>> On Wed, 10 Aug 2016 -0300, Dr. Rolf Jansen wrote: >>> ... >>> ... >>>> I just submitt

Re: your thoughts on a particualar ipfw action.

> Am 11.08.2016 um 08:06 schrieb Ian Smith : > On Wed, 10 Aug 2016 -0300, Dr. Rolf Jansen wrote: > > (just curious: whereabouts is -0300? Brazil?) Yes, I am a German living in Brazil for more than 10 years now. BTW, your mail provider is blocking my mails, perhaps, because the orig

Re: your thoughts on a particualar ipfw action.

> Am 08.08.2016 um 18:46 schrieb Dr. Rolf Jansen : > > I am almost finished with preparing the tools for geo-blocking and > geo-routing at the firewall for submission to the FreeBSD ports. > > I created a man file for the tools, see: https://cyclaero.github.io/ipdb/, > a

Re: your thoughts on a particualar ipfw action.

I am almost finished with preparing the tools for geo-blocking and geo-routing at the firewall for submission to the FreeBSD ports. I created a man file for the tools, see: https://cyclaero.github.io/ipdb/, and I added the recent suggestions on rule number/action code per country code, namely,

Re: your thoughts on a particualar ipfw action.

> Am 05.08.2016 um 02:44 schrieb Julian Elischer : > On 5/08/2016 2:22 AM, Dr. Rolf Jansen wrote: >> I am completely free of passions on this CC encoding thingy. I won't use >> this feature anyway. Please, may I suggest that the experts of the ipfw >> community come

Re: your thoughts on a particualar ipfw action.

> Am 04.08.2016 um 13:44 schrieb Ian Smith : >> On Wed, 3 Aug 2016 18:53:38 -0300, Dr. Rolf Jansen wrote: >>>> Am 03.08.2016 um 11:13 schrieb Julian Elischer : > > 'scuse savage reformatting, but I had to wrap it to read it .. and pine > has completely mangle

Re: your thoughts on a particualar ipfw action.

> Am 03.08.2016 um 11:13 schrieb Julian Elischer : > > On 2/08/2016 8:50 PM, Dr. Rolf Jansen wrote: >>> Am 02.08.2016 um 05:08 schrieb Julian Elischer : >>> >>> looking for thoughts from people who know the new IPFW features well.. >>> >>

Re: your thoughts on a particualar ipfw action.

> Am 02.08.2016 um 05:08 schrieb Julian Elischer : > > looking for thoughts from people who know the new IPFW features well.. > > > A recent addition to our armory is the geoip program that, given an address > can tell you what country it is in and given a country code, can give an ipfw > tab

Re: ipfw divert filter for IPv4 geo-blocking

> Am 01.08.2016 um 03:17 schrieb Julian Elischer : > On 30/07/2016 10:17 PM, Dr. Rolf Jansen wrote: >> I finished the work on CIDR conformity of the IP ranges tables generated by >> the tool geoip. The main constraint is that the start and end address of an >> IP block

Re: ipfw divert filter for IPv4 geo-blocking

> Am 31.07.2016 um 15:38 schrieb Ian Smith : > On Sat, 30 Jul 2016 11:17:13 -0300, Dr. Rolf Jansen wrote: >> I finished the work on CIDR conformity of the IP ranges tables >> generated by the tool geoip. The main constraint is that the start >> and end address of

Re: ipfw divert filter for IPv4 geo-blocking

> Am 29.07.2016 um 10:23 schrieb Dr. Rolf Jansen : >> Am 29.07.2016 um 06:50 schrieb Julian Elischer : >> On 29/07/2016 5:22 PM, Julian Elischer wrote: >>> On 29/07/2016 4:53 PM, Dr. Rolf Jansen wrote: >>>>> Am 28.07.2016 um 23:48 schrieb Lee Brown : >>

Re: ipfw divert filter for IPv4 geo-blocking

> Am 29.07.2016 um 06:50 schrieb Julian Elischer : > On 29/07/2016 5:22 PM, Julian Elischer wrote: >> On 29/07/2016 4:53 PM, Dr. Rolf Jansen wrote: >>>> Am 28.07.2016 um 23:48 schrieb Lee Brown : >>>> >>>> That makes sense to me. Your /20 rang

Re: ipfw divert filter for IPv4 geo-blocking

> Am 28.07.2016 um 23:48 schrieb Lee Brown : > > That makes sense to me. Your /20 range encompasses 201.222.16.0 - > 201.222.31.255. > If you want 201.222.20.0-201.222.31.255, you'll need 3 ranges: > > 201.222.20.0/22 (201.222.20.0-201.222.23.255) > 201.222.24.0/22 (201.222.24.0-201.222.27.255)

Re: ipfw divert filter for IPv4 geo-blocking

> Am 27.07.2016 um 12:31 schrieb Julian Elischer : > On 27/07/2016 9:36 PM, Dr. Rolf Jansen wrote: >>> Am 26.07.2016 um 23:03 schrieb Julian Elischer : >>> On 27/07/2016 3:06 AM, Dr. Rolf Jansen wrote: >>>> There is another tool called geoip , that I uploaded

Re: ipfw divert filter for IPv4 geo-blocking

> Am 27.07.2016 um 17:08 schrieb olli hauer : > On 2016-07-27 15:36, Dr. Rolf Jansen wrote: >> >> I finished adding a second usage form for the geoip tool, namely generation >> of ipfw table construction directives filtered by country codes. >> >>

Re: ipfw divert filter for IPv4 geo-blocking

> Am 26.07.2016 um 23:03 schrieb Julian Elischer : > On 27/07/2016 3:06 AM, Dr. Rolf Jansen wrote: >> There is another tool called geoip , that I uploaded to GitHub, and that I >> use for looking up country codes by IP addresses on the command line. >> >> ht

Re: ipfw divert filter for IPv4 geo-blocking

> Am 26.07.2016 um 13:23 schrieb Julian Elischer : > On 26/07/2016 1:41 AM, Dr. Rolf Jansen wrote: >> Once a week, the IP ranges are compiled from original sources into a binary >> sorted table, containing as of today 83162 consolidated range/cc pairs. On >> starting-up,

Re: ipfw divert filter for IPv4 geo-blocking

> Am 25.07.2016 um 12:47 schrieb Michael Sierchio : > > Writing a divert daemon is a praiseworthy project, but I think you could do > this without sending packets to user land. > > You could use tables - … > Am 25.07.2016 um 14:01 schrieb Jan Bramkamp : > > I would use a set of IPFW tables wit

ipfw divert filter for IPv4 geo-blocking

I have written a ipfw divert filter daemon for IPv4 geo-blocking. It is working flawlessly on two server installations since a week. Anyway, I am still in doubt whether I do the blocking in the correct way. Once the filter receives a packet from the respective divert socket it looks up the coun