Re: Source IP NAT

On 31/7/18 8:01 am, puneet_kumar kumar via freebsd-ipfw wrote: Hi, I am trying to change the IP of a TCP packet coming from client and send it to a server.  Client ->freebsd box --> Server. Let's say packet coming out from client has source IP: 1.1.1.1 and dst IP: 1.1.1.10, I am changing

Re: In-kernel NAT [ipfw] dropping large UDP return packets

On 14/6/18 7:44 am, Jeff Kletsky wrote: On 6/13/18 1:28 PM, Andrey V. Elsukov wrote: On 13.06.2018 23:04, Jeff Kletsky wrote: The kernel version of libalias uses m_megapullup() function to make single contiguous buffer. m_megapullup() uses m_get2() function to allocate mbuf of appropriate

Re: In-kernel NAT [ipfw] dropping large UDP return packets

On 14/6/18 3:01 am, Andrey V. Elsukov wrote: On 13.06.2018 20:16, Jeff Kletsky wrote: When a T-Mobile "femto-cell" is trying to establish its IPv4, IPSEC tunnel to the T-Mobile provisioning servers, the reassembled, 4640-byte return packet is silently dropped by the in-kernel NAT, even though

Re: In-kernel NAT [ipfw] dropping large UDP return packets

On 14/6/18 1:41 am, Michael Sierchio wrote: I see you have a case of Netgraph. Perhaps Julian will chime in. well I'm reading but not got any specific ideas at the moment.. Netgraph itself has no requirements on packet size or even contents. a node may however have some. On Wed, Jun 13,

Re: Unexpected behavior ipfw check-state with count tag or call

On 27/5/18 11:32 pm, Julian Elischer wrote: On 27/5/18 9:03 am, Jeff wrote: TL;DR If an ipfw rule's action is "count [tag]" or "call" and initiates a keep-state, when the check-state is matched, the execution not only performs the action of the original rule, but

Re: Unexpected behavior ipfw check-state with count tag or call

On 27/5/18 9:03 am, Jeff wrote: TL;DR If an ipfw rule's action is "count [tag]" or "call" and initiates a keep-state, when the check-state is matched, the execution not only performs the action of the original rule, but also the rule number. This results in the "continuation" being not where

Re: removing some error states

o use it with shell scripts. On 4/5/18 6:23 am, Alexander V. Chernikov wrote: 02.05.2018, 06:32, "Julian Elischer" <jul...@freebsd.org>: On 2/5/18 1:05 am, Julian Elischer wrote:  On 1/5/18 11:03 pm, Rodney W. Grimes wrote:  Many years ago I added code to ipfw so that

Re: removing some error states

On 2/5/18 1:05 am, Julian Elischer wrote: On 1/5/18 11:03 pm, Rodney W. Grimes wrote: Many years ago I added code to ipfw so that if -q was set it would not complain about things that were unimportant, nor would it return an error code. Such things include removing table entries

Re: removing some error states

On 1/5/18 11:03 pm, Rodney W. Grimes wrote: Many years ago I added code to ipfw so that if -q was set it would not complain about things that were unimportant, nor would it return an error code. Such things include removing table entries that are already gone and similar sorts of 'safe'

removing some error states

Many years ago I added code to ipfw so that if -q was set it would not complain about things that were unimportant, nor would it return an error code. Such things include removing table entries that are already gone and similar sorts of 'safe' operations. The idea is that you can write 'naive'

Re: IPFW NG

On 20/2/18 8:19 am, Le Baron d’Merde wrote: Hi. This is most curiosity, but I was reading this initiative to modernise/improve IPFW, and would like to know if that was abandoned or still going on? The WIKI entry date is quite old, date form 2012. https://wiki.freebsd.org/IpfwNg Project was

Re: IPFW and FTP client behind NAT

On 14/2/18 2:35 pm, wishmaster wrote: Hi, colleagues. I have the main server/router and Samba server behind this one. This Samba server at every night sends some data via FTP to another server on the Internet. The first remote server is under my power and use about the same configuration as

Re: Question that has dogged me for a while.

On 6/5/17 8:14 am, Karl Denninger wrote: On 5/5/2017 19:08, Dr. Rolf Jansen wrote: Am 05.05.2017 um 20:53 schrieb Karl Denninger <k...@denninger.net>: 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

Re: Question that has dogged me for a while.

On 6/5/17 7:53 am, Karl Denninger wrote: 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'ting firewall, which is usually the better choice

Re: Question that has dogged me for a while.

On 5/5/17 2:06 am, Karl Denninger wrote: On 5/4/2017 12:12, Rodney W. Grimes wrote: Consider the following network configuration. Internet --- Gateway/Firewall -- Inside network (including a web host) 70.16.10.1/28 192.168.0.0/24 The address of the outside is

Re: dummynet loses ports mask bits

On 1/3/17 1:54 am, Julian Elischer wrote: On 1/3/17 1:46 am, Luigi Rizzo wrote: On Tue, Feb 28, 2017 at 9:27 AM, Julian Elischer <jul...@freebsd.org> wrote: In the following example it appears that the mask bits for the port number are lost. before I raise a bug.. is there anyone who c

Re: dummynet loses ports mask bits

On 1/3/17 1:46 am, Luigi Rizzo wrote: On Tue, Feb 28, 2017 at 9:27 AM, Julian Elischer <jul...@freebsd.org> wrote: In the following example it appears that the mask bits for the port number are lost. before I raise a bug.. is there anyone who can see that I am doing anything wrong

Re: dummynet loses ports mask bits

On 1/3/17 1:27 am, Julian Elischer wrote: In the following example it appears that the mask bits for the port number are lost. before I raise a bug.. is there anyone who can see that I am doing anything wrong? just realised I'm using wrong syntax need "mask dst-port" fooled b

dummynet loses ports mask bits

In the following example it appears that the mask bits for the port number are lost. before I raise a bug.. is there anyone who can see that I am doing anything wrong? I'm not sure what the q131053 stuff is about either, but.. -- FreeBSD

Re: How to use IPFW to filter routing

On 3/2/17 2:58 pm, Ian Smith wrote: On Sun, 29 Jan 2017 18:52:58 +0100, Rakor wrote: > Hi and thanks for your reply! Just a couple of points in addition to Thomás' recent reply, which well covers most aspects .. quoting here went totally weird, so excuse any strangeness there; I'm just

Re: Ipfw+dummynet on Windows 10

On 25/11/2016 2:20 PM, Srikanth Reddy wrote: Hi Odhiambo, That's clear to me. I am not complaining that Ipfw not updated,I am requesting if any one could please help in achieving ipfw works on Windows 10 that's great help. Thanks and Regards, Srikanth. normally Luigi or one of his crew would

Re: change packets with IPFW divert

On 19/10/2016 1:56 PM, Samira Nazari wrote: Thank you for all of your comments and help. In fact, I want to divert packets for one program that do header compression What kind of header compression? Also look at netgraph. Sam, Naz On Tue, Oct 18, 2016 at 7:33 PM, Ian Smith

Re: ipfw table expiry.. how to do it..?

:12, Ian Smith <smi...@nimnet.asn.au <mailto:smi...@nimnet.asn.au>> wrote: On Mon, 12 Sep 2016 11:04:26 +0800, Julian Elischer wrote: > Unfortunately we don't have any timers on table entries, so it's not possible > to see how long an entry has be

Re: ipfw table expiry.. how to do it..?

On 11/09/2016 8:03 PM, Julian Elischer wrote: Unfortunately we don't have any timers on table entries, so it's not possible to see how long an entry has been in use, or idle. If I were to ha ve a captive portal, which placed the address of 'allowed' hosts into a table, we would have no way

ipfw table expiry.. how to do it..?

Unfortunately we don't have any timers on table entries, so it's not possible to see how long an entry has been in use, or idle. If I were to ha ve a captive portal, which placed the address of 'allowed' hosts into a table, we would have no way to time them out when they go idle. The omly

Re: Notice on upcoming ipdbtools 1.1.1

On 16/08/2016 6:11 AM, Dr. Rolf Jansen wrote: 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

Re: your thoughts on a particualar ipfw action.

On 12/08/2016 8:20 AM, Dr. Rolf Jansen wrote: 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

Re: your thoughts on a particualar ipfw action.

On 11/08/2016 9:02 AM, Dr. Rolf Jansen wrote: 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:

Re: your thoughts on a particualar ipfw action.

On 5/08/2016 12:15 PM, Michael Sierchio wrote: Wouldn't it make sense to use the ISO Numeric Code / UN M49 Numerical Code? actually it doesn't make sense. the source of data doesn't have that information in it so it would require a whole layer of mapping, including downloads. and it would have

Re: IPFW: more "orthogonal? state operations, push into 11?

On 5/08/2016 2:14 AM, Ian Smith wrote: On Fri, 5 Aug 2016 00:12:37 +0800, Julian Elischer wrote: > On 4/08/2016 6:50 PM, Andrey V. Elsukov wrote: > > On 04.08.16 06:42, Julian Elischer wrote: > > > so it's a combination of #1 and #2 in my list. I think I original

Re: your thoughts on a particualar ipfw action.

On 5/08/2016 12:44 AM, Ian Smith wrote: On Wed, 3 Aug 2016 18:53:38 -0300, Dr. Rolf Jansen wrote: > > Am 03.08.2016 um 11:13 schrieb Julian Elischer <jul...@freebsd.org>: On 2/08/2016 8:50 PM, Dr. Rolf Jansen wrote: Am 02.08.2016 um 05:08 schrieb Julian Elischer <jul...@freebs

Re: IPFW: more "orthogonal? state operations, push into 11?

On 4/08/2016 7:20 PM, Andrey V. Elsukov wrote: On 04.08.16 06:58, Julian Elischer wrote: o while thinking about states etc, it occured to me, what does THIS do on subsequent packets in the session? 10 skipto tablearg tcp from table(3) to me keep-state I think it will not work like you

Re: IPFW: more "orthogonal? state operations, push into 11?

On 4/08/2016 6:27 PM, Lev Serebryakov wrote: Hello Julian, Thursday, August 4, 2016, 6:42:45 AM, you wrote: A combination is less useful for me as you need to do: I'm against this too, as I really love orthogonality, as everybody know already, and your example is good example why. 20

Re: IPFW: more "orthogonal? state operations, push into 11?

On 4/08/2016 6:50 PM, Andrey V. Elsukov wrote: On 04.08.16 06:42, Julian Elischer wrote: so it's a combination of #1 and #2 in my list. I think I originally thought of having just #1. A combination is less useful for me as you need to do: 20 skipto 400 tcp from table(2) to me setup record

Re: IPFW: more "orthogonal? state operations, push into 11?

So while thinking about states etc, it occured to me, what does THIS do on subsequent packets in the session? 10 skipto tablearg tcp from table(3) to me keep-state On 4/08/2016 11:42 AM, Julian Elischer wrote: On 4/08/2016 3:08 AM, Andrey V. Elsukov wrote: On 03.08.16 22:07, Lev

Re: IPFW: more "orthogonal? state operations, push into 11?

On 4/08/2016 3:08 AM, Andrey V. Elsukov wrote: On 03.08.16 22:07, Lev Serebryakov wrote: On 03.08.2016 21:03, Andrey V. Elsukov wrote: 1/ ability to use keep-state without an implicit check-state. <--- most important for me. (store-state)? 2/ ability to keep-state without actually doing it

Re: IPFW: more "orthogonal? state operations, push into 11?

On 4/08/2016 12:44 AM, Lev Serebryakov wrote: On 02.08.2016 09:47, Julian Elischer wrote: I don't have rights to commit my changes, and looks like I can not persuade others that my changes are Ok as-is, with all changes, made on requests from reviewers. Personally, I think, that (1) + (2

Re: your thoughts on a particualar ipfw action.

Wow, this is getting to be a very useful tool. thanks for all the work. I look forward to the port.. On 4/08/2016 5:53 AM, Dr. Rolf Jansen wrote: Am 03.08.2016 um 11:13 schrieb Julian Elischer <jul...@freebsd.org>: On 2/08/2016 8:50 PM, Dr. Rolf Jansen wrote: Am 02.08.2016 um 05:08 s

Re: your thoughts on a particualar ipfw action.

On 2/08/2016 8:50 PM, Dr. Rolf Jansen wrote: Am 02.08.2016 um 05:08 schrieb Julian Elischer <jul...@freebsd.org>: 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 c

your thoughts on a particualar ipfw action.

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 table that describes all the ip addresses in that country. SO I

Re: IPFW: more "orthogonal? state operations, push into 11?

me. 3/ multiple state tables? this was discussed and I thought I saw patches but I haven't seen it going in, <-- super luxurious On 20/06/2016 9:59 PM, Julian Elischer wrote: On 16/06/2016 12:11 AM, Ian Smith wrote: On Mon, 13 Jun 2016 23:18:24 +0800, Julian Elischer wrote: > On 10/06/2016

Re: ipfw divert filter for IPv4 geo-blocking

On 1/08/2016 7:16 PM, Dr. Rolf Jansen wrote: Am 01.08.2016 um 03:17 schrieb Julian Elischer <jul...@freebsd.org>: 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

Re: ipfw divert filter for IPv4 geo-blocking

On 30/07/2016 10:17 PM, Dr. Rolf Jansen wrote: Am 29.07.2016 um 10:23 schrieb Dr. Rolf Jansen <r...@obsigna.com>: Am 29.07.2016 um 06:50 schrieb Julian Elischer <jul...@freebsd.org>: On 29/07/2016 5:22 PM, Julian Elischer wrote: On 29/07/2016 4:53 PM, Dr. Rolf Jansen wrote: Am 2

Re: ipfw divert filter for IPv4 geo-blocking

On 30/07/2016 10:17 PM, Dr. Rolf Jansen wrote: I am still a little bit amazed how ipfw come to accept incorrect CIDR ranges and arbitrarily moves the start/end addresses in order to achieve CIDR conformity, and that without any further notice, and that given that ipfw can be considered as

Re: ipfw divert filter for IPv4 geo-blocking

222.27.255) 201.222.28.0/22 (201.222.28.0-201.222.31.255) this <http://www.subnet-calculator.com/cidr.php> helps :) On Thu, Jul 28, 2016 at 7:21 PM, Dr. Rolf Jansen <r...@obsigna.com> wrote: Am 27.07.2016 um 12:31 schrieb Julian Elischer <jul...@freebsd.org>: On 27/07/2016 9:36 PM

Re: ipfw divert filter for IPv4 geo-blocking

trimming On 27/07/2016 11:51 PM, Ian Smith wrote: On Wed, 27 Jul 2016 10:03:01 +0800, Julian Elischer wrote: [...] > country without changing everything else. > (the downside is that dynamic skipto's are not very efficient as they do a > linear search of the rules, whe

Re: ipfw divert filter for IPv4 geo-blocking

On 27/07/2016 9:36 PM, Dr. Rolf Jansen wrote: Am 26.07.2016 um 23:03 schrieb Julian Elischer <jul...@freebsd.org>: 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 add

Re: ipfw divert filter for IPv4 geo-blocking

On 27/07/2016 3:06 AM, Dr. Rolf Jansen wrote: Am 26.07.2016 um 13:23 schrieb Julian Elischer <jul...@freebsd.org>: 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 consol

Re: ipfw divert filter for IPv4 geo-blocking

On 26/07/2016 1:01 AM, Jan Bramkamp wrote: On 25/07/16 16:28, Dr. Rolf Jansen wrote: 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

Re: ipfw divert filter for IPv4 geo-blocking

On 26/07/2016 1:41 AM, Dr. Rolf Jansen wrote: 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

Re: IPFW: more "orthogonal? state operations, push into 11?

On 16/06/2016 12:11 AM, Ian Smith wrote: On Mon, 13 Jun 2016 23:18:24 +0800, Julian Elischer wrote: > On 10/06/2016 5:11 AM, Lev Serebryakov wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA512 > > > > On 07.06.2016 00:53, Andrey V. Elsukov w

Re: IPFW: more "orthogonal? state operations, push into 11?

On 10/06/2016 5:11 AM, Lev Serebryakov wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 07.06.2016 00:53, Andrey V. Elsukov wrote: looking at provided description and examples, seems the main task you want to solve is problem with NAT. But from my point of view, you are trying to

Re: IPFW: more "orthogonal? state operations, push into 11?

On 7/06/2016 10:31 PM, Ian Smith wrote: On Tue, 7 Jun 2016 00:53:23 +0300, Andrey V. Elsukov wrote: > On 06.06.16 22:41, Lev Serebryakov wrote: > > > > I still hope to see https://reviews.freebsd.org/D1776 committed before > > 11-RELEASE. > > > > It seems to me, that I does

Re: IPFW: more "orthogonal? state operations, push into 11?

On 7/06/2016 4:00 PM, Andrey V. Elsukov wrote: On 07.06.16 09:31, wishmaster wrote: With the following patch you will be able create two different states, I think, and solve your task with NAT and dynamic rules: https://reviews.freebsd.org/D6674 Will there be the patch in the 11-RELEASE? Hi,

Re: IPFW: more "orthogonal? state operations, push into 11?

On 7/06/2016 3:41 AM, Lev Serebryakov wrote: I still hope to see https://reviews.freebsd.org/D1776 committed before 11-RELEASE. It seems to me, that I does everything what was requested by reviewers. Please? I think I gave a blessing a long time ago.. you are blocked by melifaro I

Re: [RFC] ipfw named states support

On 26/05/2016 6:11 PM, Dmitry Selivanov wrote: 18.05.2016 17:46, Andrey V. Elsukov пишет: We have the patch that adds named states support to ipfw. The idea is that we add a symbolic name-label to each dynamic state in addition to IP addresses, protocol and ports. This introduces new syntax for

Re: [RFC] ipfw named states support

On 18/05/2016 10:46 PM, Andrey V. Elsukov wrote: Hi All, We have the patch that adds named states support to ipfw. like it and have wished for this for along time this allows per-interface state. Can state name be set to a variable we can set or something? then we could have subroutines

Re: IPW problem

On 22/05/2016 4:39 AM, Jack Raats wrote: Hi everyone, I have the following problem. My home server has 2 NICs NIC1 bge0 ip-address 10.10.10.30 netmask 255.255.255.0 gateway 10.10.10.100 ADSL connection 10 Mbit/1 Mbit NIC2 bge1 ip-address 10.10.10.32 netmask 255.255.255.0 gateway 10.10.10.200

Re: Network goes down when installing ipfw

On 14/03/2016 7:37 AM, Julian Elischer wrote: On 11/03/2016 8:46 PM, Kulamani Sethi wrote: Dear all, I am using ipfw3. When i am installing ipfw driver in windows-7 machine the network goes down. If uninstall that driver again then network comes automatically. That means ipfw driver

Re: Network goes down when installing ipfw

On 11/03/2016 8:46 PM, Kulamani Sethi wrote: Dear all, I am using ipfw3. When i am installing ipfw driver in windows-7 machine the network goes down. If uninstall that driver again then network comes automatically. That means ipfw driver does not support. I have also

Re: ipwf dummynet vs. kernel NAT and firewall rules

On 10/03/2016 11:35 AM, Mark Felder wrote: On Thu, Mar 10, 2016, at 00:53, Ian Smith wrote: On Wed, 9 Mar 2016 15:02:18 -0800, Don Lewis wrote: > On 9 Mar, Don Lewis wrote: > > On 9 Mar, Don Lewis wrote: > >> On 9 Mar, Don Lewis wrote: > >>> On 9 Mar, Freddie Cash wrote: >

Re: ipwf dummynet vs. kernel NAT and firewall rules

On 9/03/2016 9:32 AM, Don Lewis wrote: I'm trying to add FQ-CoDEL AQM to my FreeBSD 10 firewall box using this patch: , but I'm running into a problem that I think is caused by an interaction between in-kernel NAT and dummynet. I've set up two

Re: ipwf dummynet vs. kernel NAT and firewall rules

On 9/03/2016 1:00 PM, Don Lewis wrote: On 9 Mar, Don Lewis wrote: On 9 Mar, Don Lewis wrote: On 9 Mar, Freddie Cash wrote: ?Do you have the sysctl net.inet.ip.fw.one_pass set to 0 or 1? Aha, I've got it set to 1. If set to 1, the a dummynet match ends the trip through the rules, and the

Re: layer2 ipfw fwd

On 23/12/2015 11:49 PM, Mark Felder wrote: On Mon, Dec 21, 2015, at 08:40, Julian Elischer wrote: This is EXACTLY what the cisco/ironport web filter appliance does... If we had this in FreeBSD nobody would have to reinvent the wheel to build a similar appliance, right? And it might allow

Re: Set a deny rule for a URL in IPFW by its domain name

On 30/11/2015 8:02 PM, Ian Smith wrote: On Mon, 30 Nov 2015 16:48:49 +0530, Kulamani Sethi wrote: > Hi all, >I am using ipfw3, can i block a URL by its domain name? When i am > setting rules in IPFW by its domain name, it simple set rule by its > corresponding IP. > Here example

Re: Kernel NAT issues

nt=KB24639=search> Yes just like that. Regards, Nathan On 19 Nov 2015, at 2:46 am, Ian Smith <smi...@nimnet.asn.au <mailto:smi...@nimnet.asn.au>> wrote: On Wed, 18 Nov 2015 22:17:29 +0800, Julian Elischer wrote: On 11/18/15 8:40 AM, Nathan Aherne wrote: For some reason hair

Re: Kernel NAT issues

ter/index?page=content=KB24639=search Yes just like that. Regards, Nathan On 19 Nov 2015, at 2:46 am, Ian Smith <smi...@nimnet.asn.au <mailto:smi...@nimnet.asn.au>> wrote: On Wed, 18 Nov 2015 22:17:29 +0800, Julian Elischer wrote: On 11/18/15 8:40 AM, Nathan Aherne wrote: For so

Re: Kernel NAT issues

On 11/18/15 8:40 AM, Nathan Aherne wrote: For some reason hairpin (loopback nat or nat reflection) does not seem to be working, which is why I chose IPFW in the first place. it would be good to see a diagram of what this actually means. ___

Re: ipfw delete 100-300

On 8/13/15 10:41 PM, Ian Smith wrote: On Thu, 13 Aug 2015 16:30:15 +0200, Luigi Rizzo wrote: On Thu, Aug 13, 2015 at 4:00 PM, Ian Smith smi...@nimnet.asn.au wrote: On Thu, 13 Aug 2015 12:24:31 +0800, Julian Elischer wrote: BTW, any ideas as to what causes this? # ipfw show

Re: ipfw delete 100-300

On 8/13/15 10:41 PM, Ian Smith wrote: On Thu, 13 Aug 2015 16:30:15 +0200, Luigi Rizzo wrote: On Thu, Aug 13, 2015 at 4:00 PM, Ian Smith smi...@nimnet.asn.au wrote: On Thu, 13 Aug 2015 12:24:31 +0800, Julian Elischer wrote: BTW, any ideas as to what causes this? # ipfw show

Re: ipfw delete 100-300

BTW, any ideas as to what causes this? # ipfw show [...] 00400 00 deny ip from 10.12.1.0/24 to any in recv xn0 00500 0 16045693110842147038 deny ip from 204.109.63.0/25 to any in recv xn1 00600 00 allow ip from any to any in recv xn1 [...]

Re: ipfw delete 100-300

On 8/3/15 10:50 PM, Alexander V. Chernikov wrote: 03.08.2015, 17:14, Ian Smith smi...@nimnet.asn.au: On Mon, 3 Aug 2015 17:38:18 +0800, Julian Elischer wrote: my reading of the code I can see that 'ipfw delete 100-300' doesn't work (well I know it doesn't work, but I had thought

Re: keep-state and in-kernel NAT exposes local ip on external interface

/ On 29 July 2015 at 22:03, Julian Elischer jul...@freebsd.org mailto:jul...@freebsd.org wrote: On 7/29/15 5:26 PM, bycn82 wrote: /Hi Julian,/ / / /So below are the rules in your example/ / / /5 skipto 10 from A to B / /6 skipto 11 from any to any

Re: keep-state and in-kernel NAT exposes local ip on external interface

On 7/29/15 3:43 AM, Lev Serebryakov wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 28.07.2015 08:30, Ian Smith wrote: I have global lack of any spare time (and all my FreeBSD activity is only a hobby) for last ~2 months. I see the end of this unfortunate state of affairs in near

Re: keep-state and in-kernel NAT exposes local ip on external interface

packets at the same time./ / / /so because C -D is already in the dynamic table it triggers on 10 and never reaches 11. see? you fell for it too. / /Regards,/ /bycn82/ On 29 July 2015 at 15:39, Julian Elischer jul...@freebsd.org mailto:jul...@freebsd.org wrote: On 7/29/15 3:43 AM, Lev

Re: ipfw on just inbound and not outbound

On 4/15/15 5:09 AM, hiren panchasara wrote: Apologies if this is something silly but I want to completely eliminate ipfw from outgoing traffic perspective. I just want to have it on incoming. I can always add allow ip from any to any out as the first rule but that is still ipfw doing something.

Re: [RFC][patch] New keep-state-only option (version 3)

On 2/4/15 5:24 PM, Lev Serebryakov wrote: -- Re-installation of state (with second, third, etc... packet of connection) should update TCP state of state (sorry!), or it will die in 10 seconds. This version seems to be final (apart from name of new option!). It works perfectly on my

Re: [RFC][patch] New keep-state-only option (version 3)

On 2/4/15 6:08 PM, bycn82 wrote: /Cool, But maybe not all people are following this topic, so can you please simplify it by answering below question in order to allow more people to know what is going on here. / /What kind of problem you are facing and how does your patch resolve it? /

Re: [RFC][patch] Two new actions: state-allow and state-deny

On 2/4/15 5:22 PM, Lev Serebryakov wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 04.02.2015 08:13, Julian Elischer wrote: yes I think keep-state should be deprecated and replaced or supplemented by 'save_state' that does NOT do an implicit 'check-state'.. I don't know whose idea

Re: [RFC][patch] New keep-state-only option

On 2/4/15 12:13 AM, Lev Serebryakov wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Ok, allow-state/deny-state was very limited idea. Here is more universal mechanism: new keep-state-only (aliased as record-only) option, which works exactly as keep-state BUT cancel match of rule

Re: [RFC][patch] Two new actions: state-allow and state-deny

On 2/3/15 6:23 PM, Lev Serebryakov wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 03.02.2015 13:04, Ian Smith wrote: Now to make stateful firewall with NAT you need to make some not very readable tricks to record state (allow) of outbound connection before NAT, but pass packet to

Re: [RFC][patch] New keep-state-only option (version 2)

On 2/4/15 12:55 AM, Lev Serebryakov wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 03.02.2015 19:13, Lev Serebryakov wrote: Ok, allow-state/deny-state was very limited idea. Here is more universal mechanism: new keep-state-only (aliased as record-only) option, which works exactly

Re: [RFC][patch] New keep-state-only option

On 2/4/15 1:32 PM, Julian Elischer wrote: On 2/4/15 12:13 AM, Lev Serebryakov wrote: And variants with multiple NATs and nat global becomes as easy as this, too! No stupid skipto, no keep-state at incoming from local network parts of firewall, nothing! P.S. I HATE this all any to any part

Re: [RFC][patch] Two new actions: state-allow and state-deny

On 2/3/15 5:30 PM, Lev Serebryakov wrote: looking at my own rules I don't seem to have a problem.. You have check-state only once, on entrance, before all NATs, so it could work only for packets which don't need NAT. And looks like (correct me if I'm wrong) you don't try to track states of

Re: [RFC][patch] Two new actions: state-allow and state-deny

On 2/3/15 3:17 AM, Lev Serebryakov wrote: I propose two new actions: state-allow and state-deny. They imply keep-state and create new dynamic rules, when called directly, but pass packet to NEXT rule after that (don't stop search). When they are called as dynamic rule, they acts as

Re: Why ipfw didn't filter neither log DHCP packets ?

On 1/5/15 9:51 PM, Luigi Rizzo wrote: On Mon, Jan 5, 2015 at 2:41 PM, Olivier Cochard-Labbé oliv...@cochard.me wrote: I believe that when Luigi says that acts before the firewall has a chance to see the packets, he was not speaking of the RC script order, but about the FreeBSD network stack

Re: Questions about ipfw

On 11/15/14, 12:13 AM, Egoitz Aurrekoetxea wrote: Good afternoon, I wanted to formulate a couple of questions I’m doing my self some time ago. 1 - With Linux, Iptables and mod_conntrack_ftp you can allow only connecting to unprivileged port ranges for ftp passive mode to ip addresses who have

Re: net.inet{,6}.fw.enable in /etc/rc

On 9/23/14, 2:01 AM, Andrey V. Elsukov wrote: On 21.09.2014 09:58, Hiroki Sato wrote: Hi, I would like your comments about the attached patch to /etc/rc. The problem I want to fix by this patch is as follows. net.inet{,6}.fw.enable are set to 1 by default at boot time if IPFW kernel

Re: ipfw named objejcts, table values and syntax change

On 8/2/14, 5:08 AM, Alexander V. Chernikov wrote: Hello all. I'm currently working on to enhance ipfw in some areas. The most notable (and user-visible) change is named table support. The other one is support for different lookup algorithms for different key types. For example, new ipfw

Re: kern/189720: [ipfw] [patch] pps action for ipfw

On 5/29/14, 11:30 PM, bycn82 wrote: I got it, if the HZ=3, it always cannot meet the 1 packet per 500ms perfectly. But if we to X packet per Y ticks, actually the result is the same, still cannot meet the 1 packet per 500 ms perfectly, instead, the packet per Y ticks will force user to use

Re: kern/189720: [ipfw] [patch] pps action for ipfw

On 5/29/14, 11:30 PM, bycn82 wrote: I got it, if the HZ=3, it always cannot meet the 1 packet per 500ms perfectly. But if we to X packet per Y ticks, actually the result is the same, still cannot meet the 1 packet per 500 ms perfectly, instead, the packet per Y ticks will force user to use

Re: kern/189720: [ipfw] [patch] pps action for ipfw

. the user parameter needs to be pps.. you need to convert in internally to a fixedpoint representation of PPT. Regards, Bycn82 -Original Message- From: Julian Elischer [mailto:jul...@freebsd.org] Sent: 30 May, 2014 22:40 To: bycn82; 'Luigi Rizzo'; freebsd-ipfw@FreeBSD.org Subject: Re

Re: feature of `packet per second`

On 4/30/14, 8:52 PM, bycn82 wrote: Hi `packet per second` it is easy to be implemented using iptables, there is a module named `recent`, but in using ipfw, Do we have any solution to fulfill it? check the link below https://forums.freebsd.org/viewtopic.php?f=44t=42933p=258441#p258441 since

Re: kern/188543: [ipfw] ipfw option `in` is not working on FreeBSD10

On 4/16/14, 11:40 PM, bycn82 wrote: Hi According to the `loop` in the chk() function, everytime it was invoked, the arg will be checked against `the chain`, so I assumed that the same is always the same, I saw that, `the chain` is always `V_layer3_chain`, but I did not find any V_layer2_chain

Re: ipfw dynamic rules

On 3/23/14, 6:16 AM, Ian Smith wrote: On Sat, 22 Mar 2014 22:39:36 -0700, Julian Elischer wrote: reposting with a useful subject line and more comments On 3/22/14, 10:33 PM, Julian Elischer wrote: in ipfw that's up to you.. but I usually put the check-state quite early

Re: ipfw dynamic rules

On 3/23/14, 8:00 AM, Matthew D. Fuller wrote: On Sun, Mar 23, 2014 at 07:47:29AM -0700 I heard the voice of Julian Elischer, and lo! it spake thus: comments welcome (bugs expected) /sbin/ipfw table add 13 0.0.0.0/8 /sbin/ipfw table add 13 10.0.0.0/8 /sbin/ipfw table add 13 169.254.0.0/16

Re: URGENT?

On 3/23/14, 7:56 AM, Brett Glass wrote: At 11:33 PM 3/22/2014, Julian Elischer wrote: in ipfw that's up to you.. but I usually put the check-state quite early in my rule sets. I don't, because I want packets to touch as few rules as possible for the sake of efficiency. One check state can

Re: ipfw dynamic rules

On 3/23/14, 10:08 AM, Michael Sierchio wrote: Thanks, Julian, this is sort of independent confirmation of something I've been doing. I've heard folks complain about efficiency of NAT (more so when using natd/DIVERT), and then saw that they matched every packet on a nat rule - 2 or 4 times.

Re: URGENT?

On 3/22/14, 8:11 AM, RW wrote: On Sat, 22 Mar 2014 08:48:40 -0600 Brett Glass wrote: This is correct. And that's awkward, because you might not want all of these checks in one place. Also, if there are many dynamic rules this will slow traffic down quite a bit. in ipfw that's up to you.. but

Re: ipfw dynamic rules

reposting with a useful subject line and more comments On 3/22/14, 10:33 PM, Julian Elischer wrote: in ipfw that's up to you.. but I usually put the check-state quite early in my rule sets. On 3/22/14, 1:34 AM, Ian Smith wrote: Firstly, that's the one page in the handbook (that I know

  1   2   3   >