Re: Source IP NAT

[Julian Elischer]

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 the IP of that 
packet to 1.1.1.100 in ether_input function. Reason behind changing it in ether_input 
is to do this NAT prior to hit any IPFW rule.
Problem is that packet is not been seen on server. I did check the code path 
taken without changing ip and with changing ip all the way to ipfw code and it 
looks like it is not dropping there. I am also recalculating the ip checksum so 
this cant be an issue either. Can someone suggest me what I am doing wrong?
Puneet
___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"



well  you have several possibilties..

ipfw can act in ether_input() and you can give it a different set of 
rules to run there so that it doesn't interfere with regular ipfw 
processing in ip.


Alternatively you could use netgraph to get the packets our and pass 
them to natd though that may take a small amount of coding.



___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

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

[Julian Elischer]

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 size. If size of packet greater than 
4k it

will fail. So, if you use MTU greater than 4k or if after fragments
reassembly you get a packet with length greater than 4k, ipfw_nat()
function will drop this packet.


Thanks!!

Mystery solved...

/usr/src/sys/netinet/libalias/alias.c

#ifdef _KERNEL
/*
  * m_megapullup() - this function is a big hack.
  * Thankfully, it's only used in ng_nat and ipfw+nat.

suggests that the "old school" approach of natd might resolve 
this. I'll
give it a try when I'm close enough to the box to resolve it when 
I make

a configuration error.

I didn't look at the rest of libalias, but you, probably, can improve
this hack to use 9k or 16k mbufs. You can replace m_get2() call in
m_megapullup() with the following code:

if (len <= MJUMPAGESIZE)
mcl = m_get2(len, M_NOWAIT, MT_DATA, M_PKTHDR);
else if (len <= MJUM9BYTES)
mcl = m_getjcl(M_NOWAIT, MT_DATA, M_PKTHDR, MJUM9BYTES);
else if (len <= MJUM16BYTES)
mcl = m_getjcl(M_NOWAIT, MT_DATA, M_PKTHDR, MJUM16BYTES);
else
goto bad;



Tested and "works for me" on 11.1-RELEASE-p10 with GENERIC kernconf

8<
--- alias.c.orig    2017-07-20 16:42:02.0 -0700
+++ alias.c    2018-06-13 15:41:46.862121000 -0700
@@ -1758,7 +1758,14 @@
 if (m->m_next == NULL && M_WRITABLE(m))
     return (m);

-    mcl = m_get2(len, M_NOWAIT, MT_DATA, M_PKTHDR);
+    if (len <= MJUMPAGESIZE)
+        mcl = m_get2(len, M_NOWAIT, MT_DATA, M_PKTHDR);
+    else if (len <= MJUM9BYTES)
+        mcl = m_getjcl(M_NOWAIT, MT_DATA, M_PKTHDR, MJUM9BYTES);
+    else if (len <= MJUM16BYTES)
+        mcl = m_getjcl(M_NOWAIT, MT_DATA, M_PKTHDR, MJUM16BYTES);
+    else
+        goto bad;
 if (mcl == NULL)
     goto bad;
 m_align(mcl, len);
>8

Thanks again!


Hi Andey,  please commit..


Jeff

___
freebsd-...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"




___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

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

[Julian Elischer]

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 it
"matches" the outbound packet from less than 100 ms prior.
Are there known causes and/or resolutions for this behavior?

Is there a way to be able to "monitor" the NAT table?

(I didn't see anything obvious in the ipfw, natd, or libalias man pages.)

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 size. If size of packet greater than 4k it
will fail. So, if you use MTU greater than 4k or if after fragments
reassembly you get a packet with length greater than 4k, ipfw_nat()
function will drop this packet.


hmmm that sounds like a bug to me..

why does it fail?


___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

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

[Julian Elischer]

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, 2018 at 10:32 AM, Jeff Kletsky  wrote:


On 6/13/18 10:22 AM, Michael Sierchio wrote:

On Wed, Jun 13, 2018 at 10:16 AM, 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 it "matches"
the outbound packet from less than 100 ms prior.



Do you have a 'reass' rule before applying nat on inbound traffic?

- M


Yes, at the start of the rule set.

Reassembly confirmed to be working by wireshark examination of the ngtee
"taps" shown

$ sudo ipfw list
1 deny ip from any to any recv ng*
4 ngtee 100 ip from any to any proto udp dst-port 500,4500 in
4 ngtee 100 ip from any to any proto udp frag in
4 ngtee 110 ip from any to any proto udp dst-port 500,4500 out
4 ngtee 110 ip from any to any proto udp frag out
5 reass ip from any to any
6 ngtee 101 ip from any to any proto udp dst-port 500,4500 in //
reassembled in
6 ngtee 101 ip from any to any proto udp frag in // never should be
frags after reass
6 ngtee 111 ip from any to any proto udp dst-port 500,4500 out //
reass out
6 ngtee 111 ip from any to any proto udp frag out // never should be
frage after reass
[...]


___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"






___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

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

[Julian Elischer]

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 also the rule
number. This results in the "continuation" being not where the
check-state was executed but where the corresponding keep-state is
numbered.

yes, that is executed though not really documented.


#$%^%$ spellcheck...   expected.. not executed.





Before I either file a ticket or start to work on the code or docs,
is this intended behavior?

---

Context:

IPv4 and NAT -- Capture the "established" connections on egress by use
of a "count tag XXX keep-state :out-ifN" rule. When a "return" packet
arrives, the "check-state :out-ifN" would then tag the packet XXX,
which could be used in identifying it as it flows through the firewall
as "expected from valid connection", even as its addr:port is 
modified.
You can't "accept keep-state" as the packet still needs NAT on the 
way in.


I've tried "count tag" as well as "call" to "tag ; return" with the 
same

results, the "next" rule evaluated is the one following the keep-state
rule, not the check-state rule.


that is expected.
the way it is implemented is that the dynamic rule is basically a 
shortcut to the action part of the static rule that made it.
I didn't write it and it surprised me in the beginning but it can be 
useful as well sometimes.


(I've still got a couple other things I'm going to try as 
work-arounds.)



Once I've got my rules running here, I'd like to tackle this, but I
don't know if this is a "documentation weakness", or perhaps
unintended behavior, based on the man pages and what I've been able to
find in the code. I know the man page and comments have grown
organically since I started using ipfw back in the 4.0 days and may
not be completely up-to-date.

If there's any insight into intent of the code before I dive in, I'd
certainly appreciate it!

Thanks,

Jeff





ipfw(8):

 check-state [:flowname | :any]
 Checks the packet against the dynamic ruleset.  If a 
match is

 found, execute the action associated with the rule which
 generated this dynamic rule, otherwise move to the 
next rule.


"action associated with the rule" -- not the rule itself



ip_fw_dynamic.c has some "interesting" comments:

 * Each dynamic rule holds a pointer to the parent ipfw rule so
 * we know what action to perform. Dynamic rules are removed when
 * the parent rule is deleted. This can be changed by dyn_keep_states
 * sysctl.
 *
 * There are some limitations with dynamic rules -- we do not
 * obey the 'randomized match', and we do not do multiple
 * passes through the firewall. XXX check the latter!!!



ip_fw2.c appears to the match/dispatch:

2191 /*
2192  * Found dynamic entry, update stats
2193  * and jump to the 'action' part of
2194  * the parent rule by setting
2195  * f, cmd, l and clearing cmdlen.
2196  */

(I haven't pursued the code deeper yet)




Here are the rules used for confirming this behavior


192.168.0.100 is the management interface
10.0.0.100 is the "outside" interface, leading to the "true" gateway
172.217.11.164 is an IP of www.google.com used to drive outside 
traffic


1 reass
00010 allow via lo0
00011 deny ip from 127.0.0.0/8 to any
00012 deny ip from any to 127.0.0.0/8
00013 deny ip from ::1 to any
00014 deny ip from any to ::1
00020 allow tcp from 192.168.0.100 22 to 192.168.0.100/24 via igb2
00021 allow tcp from 192.168.0.100/24 to 192.168.0.100 dst-port 22 
via igb2
00080 skipto 90 log proto tcp src-ip 10.0.0.100 via igb0 dst-ip 
172.217.11.164 dst-port 443
00081 skipto 90 log proto tcp src-ip 172.217.11.164 src-port 443 
dst-ip 10.0.0.100 via igb0

00092 skipto 2000 log not layer2 in
00093 skipto 3000 log not layer2 out recv *
00094 skipto 4000 log not layer2 out // not recv *
00099 deny log // first-stage dispatch problem
02000 count log // ip_input
02100 count log tagged 40
02104 check-state :IP4_TAG_OUTER_outside log // "established" IPv4 
connections

02500 count log // Inbound "NAT" of IPv4
02510 allow log tagged 40 // "established" IPv4 connections,post-NAT
02999 deny log // ip_input -- DENY remaining
03000 deny log // ip_output -- forwarded
04000 count log // ip_output -- common output
04204 count log // Outbound "NAT"
04304 count log tag 40 xmit igb0 keep-state :IP4_TAG_OUTER_outside
04400 allow log tagged 40
04999 deny log // ip_output -- common output -- DENY remaining
65535 deny ip from any to any

# First packet goes out, tagged keep-state at 4304, accepted at 4400

ipfw: 80 SkipTo 90 TCP 10.0.0.100:45427 172.217.11.164:443 out via 
igb0
ipfw: 94 SkipTo 4000 TCP 10.0.0.1

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

[Julian Elischer]

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 the
check-state was executed but where the corresponding keep-state is
numbered.

yes, that is executed though not really documented.



Before I either file a ticket or start to work on the code or docs,
is this intended behavior?

---

Context:

IPv4 and NAT -- Capture the "established" connections on egress by use
of a "count tag XXX keep-state :out-ifN" rule. When a "return" packet
arrives, the "check-state :out-ifN" would then tag the packet XXX,
which could be used in identifying it as it flows through the firewall
as "expected from valid connection", even as its addr:port is modified.
You can't "accept keep-state" as the packet still needs NAT on the 
way in.


I've tried "count tag" as well as "call" to "tag ; return" with the 
same

results, the "next" rule evaluated is the one following the keep-state
rule, not the check-state rule.


that is expected.
the way it is implemented is that the dynamic rule is basically a 
shortcut to the action part of the static rule that made it.
I didn't write it and it surprised me in the beginning but it can be 
useful as well sometimes.


(I've still got a couple other things I'm going to try as 
work-arounds.)



Once I've got my rules running here, I'd like to tackle this, but I
don't know if this is a "documentation weakness", or perhaps
unintended behavior, based on the man pages and what I've been able to
find in the code. I know the man page and comments have grown
organically since I started using ipfw back in the 4.0 days and may
not be completely up-to-date.

If there's any insight into intent of the code before I dive in, I'd
certainly appreciate it!

Thanks,

Jeff





ipfw(8):

 check-state [:flowname | :any]
 Checks the packet against the dynamic ruleset.  If a 
match is

 found, execute the action associated with the rule which
 generated this dynamic rule, otherwise move to the next 
rule.


"action associated with the rule" -- not the rule itself



ip_fw_dynamic.c has some "interesting" comments:

 * Each dynamic rule holds a pointer to the parent ipfw rule so
 * we know what action to perform. Dynamic rules are removed when
 * the parent rule is deleted. This can be changed by dyn_keep_states
 * sysctl.
 *
 * There are some limitations with dynamic rules -- we do not
 * obey the 'randomized match', and we do not do multiple
 * passes through the firewall. XXX check the latter!!!



ip_fw2.c appears to the match/dispatch:

2191 /*
2192  * Found dynamic entry, update stats
2193  * and jump to the 'action' part of
2194  * the parent rule by setting
2195  * f, cmd, l and clearing cmdlen.
2196  */

(I haven't pursued the code deeper yet)




Here are the rules used for confirming this behavior


192.168.0.100 is the management interface
10.0.0.100 is the "outside" interface, leading to the "true" gateway
172.217.11.164 is an IP of www.google.com used to drive outside traffic

1 reass
00010 allow via lo0
00011 deny ip from 127.0.0.0/8 to any
00012 deny ip from any to 127.0.0.0/8
00013 deny ip from ::1 to any
00014 deny ip from any to ::1
00020 allow tcp from 192.168.0.100 22 to 192.168.0.100/24 via igb2
00021 allow tcp from 192.168.0.100/24 to 192.168.0.100 dst-port 22 
via igb2
00080 skipto 90 log proto tcp src-ip 10.0.0.100 via igb0 dst-ip 
172.217.11.164 dst-port 443
00081 skipto 90 log proto tcp src-ip 172.217.11.164 src-port 443 
dst-ip 10.0.0.100 via igb0

00092 skipto 2000 log not layer2 in
00093 skipto 3000 log not layer2 out recv *
00094 skipto 4000 log not layer2 out // not recv *
00099 deny log // first-stage dispatch problem
02000 count log // ip_input
02100 count log tagged 40
02104 check-state :IP4_TAG_OUTER_outside log // "established" IPv4 
connections

02500 count log // Inbound "NAT" of IPv4
02510 allow log tagged 40 // "established" IPv4 connections,post-NAT
02999 deny log // ip_input -- DENY remaining
03000 deny log // ip_output -- forwarded
04000 count log // ip_output -- common output
04204 count log // Outbound "NAT"
04304 count log tag 40 xmit igb0 keep-state :IP4_TAG_OUTER_outside
04400 allow log tagged 40
04999 deny log // ip_output -- common output -- DENY remaining
65535 deny ip from any to any

# First packet goes out, tagged keep-state at 4304, accepted at 4400

ipfw: 80 SkipTo 90 TCP 10.0.0.100:45427 172.217.11.164:443 out via igb0
ipfw: 94 SkipTo 4000 TCP 10.0.0.100:45427 172.217.11.164:443 out via 
igb0

ipfw: 4000 Count TCP 10.0.0.100:45427 172.217.11.164:443 out via igb0
ipfw: 4204 Count TCP 10.0.0.100:45427 172.217.11.164:443 out via igb0
ipfw: 4304 Count TCP 10.0.0.100:45427 172.217.11.164:443 out via igb0
ipfw: 4400 Accept TCP 10.0.0.100:45427 172.217.11.164:443 out via igb0

# 

Re: removing some error states

[Julian Elischer]

See inline

thanks for answering

Ont thing you need to understand is that I tend to run ipfw with a 
front-end.

for example which is more efficient:

cat <<-DONE  |ipfw -q -f /dev/stdin
    add 1 (some rule}
    [100 other  operations including table and pipe operations and 
more rules]

    DONE

vs
ipfw -f -q add 1 (some rule)
ipfw -f -q {operation}
[...] 100 more ops, same as above..


obviously the first is orders of magnitude more efficient.
I have wondered if you could feed a script into ipfw's preprocessor  
feature so that it actually generated data instead of just filtering it,

but I haven't tried it yet..
In the version I wrote for Cisco, it is a python program that is 
continually manipulating hte firewall by adding and removing table 
entries and rules as the world changes around it.
So having to not for/exec a new copy of ipfw for every operations i 
important to me.
Maybe we want to add a special mode (-I - ) to allow stdin to be used. 
using /dev/stdin is a hack.

and there is no way to get any output back.

I actually have a way to make it work as a shell script using netcat...
The server part that stays resident does:
 action ()
  {
    local LINE="$*"
    logger -p user.info -t firewall "command $LINE"
    set $LINE
    local COMMAND=$1
    shift
    case ${COMMAND} in
  setup-firewall)
    # called from rc.d/postpixel8 and from rc.conf via 
ip_filter_rules.sh

    setup_firewall $*
    ;;
[... lots of other commands ]


  if [ $MODE = "server" ]
  then
    FIREWALL_DISABLED=
    nc -U -k -l "$CONTROL_SOCKET" | while read LINE
    do
  action $LINE
    done
    logger -p user.info -t firewall "Server loop ended"
    exit 0  # server never goes below this point
  fi
and the client just does:

  if [ "$MODE" = "client" ]
  then
    echo $COMMAND $* | nc -N -U $CONTROL_SOCKET
  fi

sending high level commands to the server,
and the server, keeps state, and feeds commands out via stdout to a 
copy of ipfw that is started at the time the server starts, and keeps 
running until it quits, doing ALL the low level 'ipfw' commands..
this mode of operation if very efficient and can lead to very 
sophisticated active firewalls as the server has local state about hte 
firewall and can  manipulate it with great speed and accuracy.


anyhow.. to do this I need that the ipfw program not quit every time 
it gets something it doesn't like.
Especially things like "clear a rule  without havng to first test 
whether it is there".

or swap with a new table.. (just create an empty table of the same kind).

Or pretty much anything else that would error out.. e.g. I want most  
delete commands to be "optionally" idempotent.


calling it should be ok regardless of whether the 
rule/table/pipe/whatever already exists or has already been deleted.

Like rm -f .

Maybe a special mode for running as a client may be good.. or maybe 
ipfw is in control and fires off a given program and controls both 
stdin and stdout.
that way the script/progra can actually get feedback.  Something I've 
had a hard time doing..

also some ways to get events from the firewall would be amazing.

Maybe what I want is a libipfw.so, but I want to be able to 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 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' scripts that don't need to do
  complicated checks to see if XXX is already present or gone..
  In hte ame way that rm -f doesn't complain if the file doesn't
  exist..? You were going to delete it anyhow.

  I'd like that to continue to some of the new additions.
  for example the terribly annoying
    ??? ipfw: DEPRECATED: inserting data into non-existent table 18.
  (auto-created) (who cares?)

  and

    ?? ljcc-78# ipfw table 19 create
     ipfw: Table creation failed: File exists

  As the script needs to run multiple times, I don't care if the table
  already exists.
  but I do care about other errors.
  I don't want to have to write special wrapper code for table create
  that is different
  from the wrappers elsewhere because it has to look for return code 71
  and disregard it.
  Can we just have -q continue to ignore such errors please?

  I think there is a bigger question here, why was auto table creation
  with first insert "Deprecated" at all?   This to me just seems like
  change cause someone could change it that has no usefull purpose or
  is there some great purpose this serves?

In the &q

Re: removing some error states

[Julian Elischer]

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 that are already gone and
similar sorts of 'safe' operations.
The idea is that you can write 'naive' scripts that don't need to do
complicated checks to see if XXX is already present or gone..
In hte ame way that rm -f doesn't complain if the file doesn't
exist..? You were going to delete it anyhow.


I'd like that to continue to some of the new additions.
for example the terribly annoying
  ??? ipfw: DEPRECATED: inserting data into non-existent table 18.
(auto-created) (who cares?)

and

  ?? ljcc-78# ipfw table 19 create
   ipfw: Table creation failed: File exists

As the script needs to run multiple times, I don't care if the table
already exists.
but I do care about other errors.
I don't want to have to write special wrapper code for table create
that is different
from the wrappers elsewhere because it has to look for return code 71
and disregard it.
Can we just have -q continue to ignore such errors please?

I think there is a bigger question here, why was auto table creation
with first insert "Deprecated" at all?   This to me just seems like
change cause someone could change it that has no usefull purpose or
is there some great purpose this serves?

Same with creation of an already existing file, why did that need
to become a noisy warning/error?

Well ther eis an argument (that I disagree with in this case) that 
any unexected even is an error..


Also the new tables can have many different key type and indexing 
algorithms, which need to be  declared up front.


but I don't see that raising a fatal error for trying to delete 
something that doesn't exist or make something that already exists 
really helps much other than to make scripts more complicated. 
That's why I made it optional before.. Removing table entries that 
are not present could be an error you want to know about, but 
probably it isn't.



my biggest issue is that it bombs out when you are using it as a filter.
e.g. (manual simulation)

32Ssd# ipfw -q -f /dev/tty    < -q   "don't complain and quit on 
unimportant things  -f  "trust me I know what I'm doing"

table 3 add 1.1.1.1
table 3 add 1.1.1.1   <- no error.. this is what I want..
table 20 add 2.2.2.2
table 3 swap 20
table all list
--- table(3), set(0) ---
2.2.2.2/32 0
--- table(20), set(0) ---
1.1.1.1/32 0
table 3 swap 21  <--  doesn't quit, but doesn't generate a new 
empty 21 either :-(

table all list
--- table(3), set(0) ---
2.2.2.2/32 0
--- table(20), set(0) ---
1.1.1.1/32 0
table 21 create
table 21 create  <-- this shouldn't quit..   actually I 
wouldprefer that I didnt NEED to make the damned things. Any reference 
should make it.. (e.g. swap)

Line 6: Table creation failed: File exists
32Ssd#
  "congratulations the parent process now has to restart it.."

The Cisco/Ironport "Web Security Appliance" ran like this, with a 
python process feeding commands into a single instance of ipfw.
I don't know if it still does (Doug Ambrisko may know).  I use this 
method of running ipfw regularly, as forking and exec-ing a new copy 
of ipfw for every firewall operation is a huge waste of resources when 
you have a dynamic firewall that is constantly adding and removing 
table entries and rules, as well as doing load control with dummynet.
Last thing I need is for ipfw to start quitting on operations that 
should be idempotent.


interestingly the man page no longer shows how to run with input from 
a file in hte synopsis (though it refers to it)


   LIST OF RULES AND PREPROCESSING
 To ease configuration, rules can be put into a file which is 
processed
 using ipfw as shown in the last synopsis line.  An absolute 
pathname must
 be used.  The file will be read line by line and applied as 
arguments to

 the ipfw utility.

errr, no such example.
 I think I will look into adding a -F option to allow for input from 
a file or stdin..

and make it shut the heck up in that mode (implies -q and -f)



Julian



___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"




___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

Re: removing some error states

[Julian Elischer]

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' operations.
The idea is that you can write 'naive' scripts that don't need to do
complicated checks to see if XXX is already present or gone..
In hte ame way that rm -f doesn't complain if the file doesn't
exist..? You were going to delete it anyhow.


I'd like that to continue to some of the new additions.
for example the terribly annoying
  ??? ipfw: DEPRECATED: inserting data into non-existent table 18.
(auto-created) (who cares?)

and

  ?? ljcc-78# ipfw table 19 create
   ipfw: Table creation failed: File exists

As the script needs to run multiple times, I don't care if the table
already exists.
but I do care about other errors.
I don't want to have to write special wrapper code for table create
that is different
from the wrappers elsewhere because it has to look for return code 71
and disregard it.
Can we just have -q continue to ignore such errors please?

I think there is a bigger question here, why was auto table creation
with first insert "Deprecated" at all?   This to me just seems like
change cause someone could change it that has no usefull purpose or
is there some great purpose this serves?

Same with creation of an already existing file, why did that need
to become a noisy warning/error?

Well ther eis an argument (that I disagree with in this case) that any 
unexected even is an error..


Also the new tables can have many different key type and indexing 
algorithms, which need to be  declared up front.


but I don't see that raising a fatal error for trying to delete 
something that doesn't exist or make something that already exists 
really helps much other than to make scripts more complicated. That's 
why I made it optional before.. Removing table entries that are not 
present could be an error you want to know about, but probably it isn't.


___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

removing some error states

[Julian Elischer]

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' scripts that don't need to do 
complicated checks to see if XXX is already present or gone..
In hte ame way that rm -f doesn't complain if the file doesn't 
exist..  You were going to delete it anyhow.



I'd like that to continue to some of the new additions.
for example the terribly annoying
    ipfw: DEPRECATED: inserting data into non-existent table 18. 
(auto-created) (who cares?)


and

   ljcc-78# ipfw table 19 create
 ipfw: Table creation failed: File exists

As the script needs to run multiple times, I don't care if the table 
already exists.

but I do care about other errors.
I don't want to have to write special wrapper code for table create 
that is different
from the wrappers elsewhere because it has to look for return code 71 
and disregard it.

Can we just have -q continue to ignore such errors please?

thanks




___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

Re: IPFW NG

[Julian Elischer]

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 never done.
I believe that a lot of newer work in ipfw made this largely un-needed.
still looks interesting though.

This happens a lot.  A project fails to get critical mass or mindshare 
and other things get the priority.



Thanks!



___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

Re: IPFW and FTP client behind NAT

[Julian Elischer]

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 main plus FTPD (port 2112) daemon.
The second remote server is not in my power and we use is as backup storage and 
as I know OS is f...ing Linux.

When I connect to the first server and transmit a very big file with transmission duration > 
300 sec, the control channel (port pair 36313 <-> 2112) always "recreated" when 
the expiration timer aim to zero.

root@xxx: ipfw -d show|grep '111.222.230.62'
15150   695255 (29s) STATE tcp 111.222.230.62 36313 <-> 
111.222.13.195 2112 :nts
15150   320423   321696704 (300s) STATE tcp 111.222.230.62 60759 <-> 
111.222.13.195 49758 :nts

The issue is with the second remote server. When I transmit a very big file, the control 
channel does not "recreated" and transmitting this file and all the next is 
always fails.

root@xxx: ipfw -d show|grep '111.222.0.7'
03200  2985778  2299927348 (300s) STATE tcp 111.222.0.253 63307 <-> 111.222.0.7 
44678 :nts
03200   594622 (6s) STATE tcp 111.222.0.253 63623 <-> 111.222.0.7 
21 :nts

root@xxx: ipfw -d show|grep '111.222.0.7'
03200  3137837  2414765852 (300s) STATE tcp 111.222.0.253 63307 <-> 111.222.0.7 
44678 :nts

The main server/router uses IPFW and in most places dynamic rules. Is 
workaround I have added one rule on external interface:

$cmd 5153 allow log tcp from any 21 to any 1024-65535 # ipfw - ftp issue

But I want find the problem.

Thanks,
Vitaly
___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"



can you check the values of the keep-alive timers on all 3 systems?

And possibly the firewall on system3 may block keepalive packets..


[jelischer@bob ~/p4/private/inverness-integ1]$ sysctl 
net.inet.tcp.always_keepalive

net.inet.tcp.always_keepalive: 1

[jelischer@bob ~/p4/private/inverness-integ1]$ sysctl 
net.inet.tcp.keepidle

net.inet.tcp.keepidle: 720

that's 2 hours for example.

setting it to less than 30 should make your control session 
include keepalive packets


also look at your ipfw table and see if this can help you:



 Dynamic rules expire after some time, which depends on the 
status of the

 flow and the setting of some sysctl variables.  See Section SYSCTL
 VARIABLES for more details.  For TCP sessions, dynamic rules can be
 instructed to periodically send keepalive packets to refresh the 
state of

 the rule when it is about to expire.

 See Section EXAMPLES for more examples on how to use dynamic rules.


___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

Re: Question that has dogged me for a while.

[Julian Elischer]

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 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 assume, the second level domain name in question is
example.com, and your web server would be accessed by
www.example.com, while other services, e.g. mail are served from
other sites on the internet.

I believe this is a much cleaner solution thanusing double NAT.
(see also my solution for if the server is also freebsd)
even though we have a nice set of new IPFW capabilities that can do
this, I still think double nat is an over complication of the system.


Well, the DNS answer is one that works IF you control the zone in
question every time. ...

I do not understand "control the zone ... every time".

I set up my transparent zones 5 years ago and never touched it again, and I don't see any 
"illegal" packets on my network caused by this either.

I understand that you actually didn't grasp the transparent zone technic.

Happy double nat'ting :-D

On the contrary I do understand it (and how to do it), along with how to
throw "off-network" packets at the other host.  Both ways work (unbound
is arguably simpler than BIND, but it'll work in both cases) but the
point is that you then must keep two things in sync rather than do one
thing in one place.

If double-nat'ing isn't supposed to work with in-kernel ipfw nat because
the first nat never leaves an interface then it is what it is, but if it
IS supposed to work  then is not this misfeature a roach on the floor
that perhaps ought to get squashed?
I think the problem MAY be that the return packets from the internal 
(reverse) nat are taking the same path as the original packets. 
(confusing libalias)
You are saying that the packets coming from 192.168.x.x are CLIENT 
packets and then you expect the packets from the server to be treated 
the differently, even tough they are the same. I think the NAT doesn't 
know which way to apply them as.






___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

Re: Question that has dogged me for a while.

[Julian Elischer]

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.

IMHO a DNS based solution is much more effective.

On my gateway I have running the caching DNS resolver Unbound. Now
let's assume, the second level domain name in question is
example.com, and your web server would be accessed by
www.example.com, while other services, e.g. mail are served from
other sites on the internet.

I believe this is a much cleaner solution thanusing double NAT.
(see also my solution for if the server is also freebsd)
even though we have a nice set of new IPFW capabilities that can do
this, I still think double nat is an over complication of the system.


Well, the DNS answer is one that works IF you control the zone in
question every time.  I'm loathe to stick "illegal" (e.g. bad IP number)
packets on a network in any event, so while yeah, that'll work I'd
rather not.


Interestingly the "bad" IP packets are no different than the packets 
you are  seeing on the network anyhow (with nat).

You just deliver them to a different place.
Effectively you are turning on the transparent proxy support in the 
kernel and making the gateway a transparent proxy for your clients. 
(but only for your own server)


for example  if your client is 192.168.0.2
and your server is 192.168.0.3 and your external address is 8.8.8.9,

Then what you are asking for is a way that your client can make a 
session where the remote address is 8.8.8.9 and the local address is 
192.168.0.2.
You are going to generate these packets no matter what you do because 
they are what you asked to do even if you are NATing.


The packets when bounced to the server STILL look like 
src=192.169.0.2, dest=8.8.8.9 and the server(FreeBSD or Linux with TP 
support only) will consume them as such.
The server will produce a packet that looks like src=8.8.8.9, 
dest=192.168.0.2.These packets look exactly like the packets that 
would be returning from the NAT to the client had you used nat.


so, overall, you are not introducing any packets onto your network 
that wouldn't have been there anyhow.
They look exactly like the traffic would look between the NAT and the 
client.
The difference is that it is way more efficient, because the return 
packets take no processing at all.


The advantage of setting up a DNS (mostly) forwarding proxy is that 
what is happening is absolutely visible on the wire.

Nothing is pretending to be anything it is not.

The nat option on the other hand.
 (don't get me wrong, I am sure it would work given enough work) is 
that it just has more moving parts and will make it more complicated 
to get your firewall correct in other cases.

I like ipfw and it's nat, it's just more complicated in some cases.


The "set up a fake forward" zone thing works too, but it shouldn't have to.

This /should /work on a generalized basis but doesn't (ue1 is on the
public address 70.169.168.7, ue0 on private address 192.168.10.200, the
host being "twisted to/hole punched" is on 192.168.10.100:

# Set up the NAT configuration
#
 ${fwcmd} nat 100 config if ue1 log same_ports reset
redirect_port tcp 192.168.10.100:2552 2552
 ${fwcmd} nat 200 config ip 192.168.10.200 log same_ports reset



shouldn't one of these be declared to be a reverse nat?




060000   0 nat 200 ip4 from 192.168.0.0/16 2552 to 192.168.10.200
06010 1521  726601 nat 100 ip4 from any to me recv ue1
070000   0 check-state :default

080006 312 nat 200 ip4 from 192.168.0.0/16 to 70.169.168.7
080010   0 count log ip4 from 192.168.10.200 to any dst-port 2552
08002 2125 2408339 nat 100 ip4 from 192.168.0.0/16 to any xmit ue1
080090   0 deny log ip4 from 192.168.0.0/16 to any xmit ue1

A "telnet 70.169.168.7 2552" from outside works perfectly well.  But the
second NAT should cause a "telnet 70.169.168.7 2552" from an
internet-network host to work also.  It doesn't.

8000 gets the packet (a telnet attempt from inside to port 2552) and
allegedly is supposed to NAT it.  It does not.  The following rule,
which is where execution should continue after it NATs it, should match
but no packet ever comes back into the stack -- nor does it show up on
the wire (tcpdump fails to show it.)  I have verbose logging on in
sysctl and none of the deny lines in the remainder of the ipfw config
file trap it either.

The *other* NAT instance on the same box (to translate other things on
the same network out to the Internet at large and perform the hole
punch) works perfectly well.

This looks like a bug in the code -- unless there's a requirement that a
packet in the kernel is marked to be enqueued for emission on an actual
physical interface before it will transl

Re: Question that has dogged me for a while.

[Julian Elischer]

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 FICTIONAL, by the way.

For policy reasons I do NOT want the gateway machine to actually have
the host on it.  There may be a number of things running on there but
for the instant moment let's assume a standard pedestrian web host on
port 80.

I have DNS pointing at "webhost.domain" @ 70.16.10.1.

I have NAT on the gateway (NAT internal to the kernel), and a "hole
punch" in there with redirect_port tcp 192.168.1.1:80 70.16.10.1:80 as
pat of the nat configuration statement.

This works fine for anyone on the outside.  HOWEVER, anyone on the
INTERNAL network cannot see the host.

My NAT configuration looks like this:

#
# Now divert all inbound packets that should go through NAT. Since this
is NAT
# it can only match a packet that previously was NATted on the way out.
#
 ${fwcmd} add 6000 nat 100 ip4 from any to me recv ${oif}
#
# Check stateful rules; we want to go there directly if there is a match
#
 ${fwcmd} add 7000 check-state
#
# Now pick up all *outbound* packets that originated from an inside address
# and put them through NAT.  We then have
# a packet with a local source address and we can allow it to be sent.
# Therefore, if the packet is outbound let it pass and be done with it.
#
 ${fwcmd} add 8000 nat 100 ip4 from 192.168.0.0/16 to any xmit ${oif}

${fwcmd} add 8001 nat 100 ip4 from 192.168.0.0/16 to ${oip}

 ${fwcmd} add 8009 deny log ip4 from 192.168.0.0/16 to any xmit
${oif}
 ${fwcmd} add 8010 pass ip4 from ${onet} to any xmit ${oif}

Without the ">>" line I get nothing; the packets get to the gateway and
disappear.

With the ">>" line I DO get the packets re-emitted on the internal
interface HOWEVER there is no translation to the internal interface IP
on the gateway box.  So what I see on the internal box is this:

11:19:16.369634 IP 192.168.10.40.60924 > 192.168.10.100.11443: Flags
[S], seq 292171178, win 8192, options [mss 1460,nop,wscale
8,nop,nop,sackOK], length 0
11:19:16.369662 IP 192.168.10.100.11443 > 192.168.10.40.60924: Flags
[S.], seq 3088872007, ack 292171179, win 65535, options [mss
1460,nop,wscale 6,sackOK,eol], length 0

Which won't work because the internal box got and sent this:

What is the NAT command running at instance 100?
Does it have an -alias_address of inside IP of router?
Are you tryint to use the same Nat instance to do both
the global internet acess translation and this special
inside loop back translation?  If so that usually can
not be made to work.

Aha.  That's probably the problem -- I need a second instance.

Here's the entire salient section:


# Set up the NAT configuration; there are multiple entries that have to
be here
# because we redirect a bunch of ports around so we can see things from the
# outside -- specifically, webcams and the HomeDaemon server.
#
 ${fwcmd} nat 100 config ip ${oip} log same_ports reset
redirect_port tcp (whole bunch of stuff)

#
# Stop spoofing
#
 ${fwcmd} add 2010 deny log all from ${inet} to any not ipsec in
via ${oif}
 ${fwcmd} add 2020 deny log all from ${onet} to any in via ${iif}
 if [ -n "$inet6" ]; then
 ${fwcmd} add 2040 deny all from ${inet6} to any in via
${oif6}
 if [ -n "$onet6" ]; then
 ${fwcmd} add 2050 deny log all from ${onet6} to
any in \
 via ${iif6}
 fi
 fi

 ${fwcmd} add 3000 deny log all from ${onet} to any recv ${iif}

#
# This table is a list of denied addresses that tried to attack us.  Updated
# by sshguard.  Anything coming inbound from the outside is blocked.  We
also
# block anything on the "screw you" lists (two)
#
 ${fwcmd} add 4000 deny log all from table\(22\) to any recv ${oif}
 ${fwcmd} add 4010 deny all from any to ${foscam}
 ${fwcmd} add 4020 deny log all from ${china} to any via ${oif}
#
# Anything related to RFC1918 or the Manning range that comes in on
# the external interface (shouldn't happen) gets tossed immediately, EXCEPT
# for RFC1918 stuff coming in via IPSEC.  That we must pass or our IPSEC
# gateway will not work.
#
 ${fwcmd} add 5000 deny log all from ${rfc1918} to any not ipsec
recv ${oif}
 ${fwcmd} add 5010 deny log all from ${manning} to any recv ${oif}

#
# Now divert all inbound packets that should go through NAT. Since this
is NAT
# it can only match a packet that previously was NATted on the way out.
#
 ${fwcmd} add 6000 nat 100 ip4 from any to me recv ${oif}
#
# Check stateful rules; we want to go there directly if there is a match
#
 ${fwcmd} add 7000 check-state
#
# Now pick up all *outbound* packets that originated from an 

Re: dummynet loses ports mask bits

[Julian Elischer]

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 can see that I am doing 
anything

wrong?

I'm not sure what the q131053 stuff is about either, but..

q131053 is the internal name for the queue associated with the pipe
(pipe# + 0x1).
I am not sure if the mask supports ip/port notation (dst-ip covers
only the address part).
Of course the real bug is that the parser should be more strict and 
complain
about extra/ignored fields. But the ipfw parser is full of these 
things.


cheers
luigi


my error is I should have used dst-port 0x000f  not /0x000f
 seems to be working now



--
FreeBSD fb10-cc03.kumo.com 10.3-RELEASE-p16 : Wed Feb 22 14:40:53 
UTC 2017

amd64

fb10-cc03# ipfw pipe 11 config mask dst-ip 0x00ff/0x0fff bw 
200Kbit/s


fb10-cc03# ipfw pipe show
00011: 200.000 Kbit/s0 ms burst 0
q131083  50 sl. 0 flows (1 buckets) sched 65547 weight 0 lmax 0 pri 0
droptail
  sched 65547 type FIFO flags 0x1 64 buckets 0 active
 mask:  0x00 0x/0x -> 0x00ff/0x





btw ipfw pipe show
only shows queues currently active. is there a way to see 'queues 
active in the last few seconds"?




___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"



___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

Re: dummynet loses ports mask bits

[Julian Elischer]

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?

I'm not sure what the q131053 stuff is about either, but..

q131053 is the internal name for the queue associated with the pipe
(pipe# + 0x1).
I am not sure if the mask supports ip/port notation (dst-ip covers
only the address part).
Of course the real bug is that the parser should be more strict and complain
about extra/ignored fields. But the ipfw parser is full of these things.

cheers
luigi


my error is I should have used dst-port 0x000f  not /0x000f
 seems to be working now



--
FreeBSD fb10-cc03.kumo.com 10.3-RELEASE-p16 : Wed Feb 22 14:40:53 UTC 2017
amd64

fb10-cc03# ipfw pipe 11 config mask dst-ip 0x00ff/0x0fff bw 200Kbit/s

fb10-cc03# ipfw pipe show
00011: 200.000 Kbit/s0 ms burst 0
q131083  50 sl. 0 flows (1 buckets) sched 65547 weight 0 lmax 0 pri 0
droptail
  sched 65547 type FIFO flags 0x1 64 buckets 0 active
 mask:  0x00 0x/0x -> 0x00ff/0x






___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

Re: dummynet loses ports mask bits

[Julian Elischer]

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 by the fact there was no error.



I'm not sure what the q131053 stuff is about either, but..

--
FreeBSD fb10-cc03.kumo.com 10.3-RELEASE-p16 : Wed Feb 22 14:40:53 
UTC 2017  amd64


fb10-cc03# ipfw pipe 11 config mask dst-ip 0x00ff/0x0fff bw 
200Kbit/s


fb10-cc03# ipfw pipe show
00011: 200.000 Kbit/s0 ms burst 0
q131083  50 sl. 0 flows (1 buckets) sched 65547 weight 0 lmax 0 pri 
0 droptail

 sched 65547 type FIFO flags 0x1 64 buckets 0 active
mask:  0x00 0x/0x -> 0x00ff/0x

___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"



___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

dummynet loses ports mask bits

[Julian Elischer]

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 fb10-cc03.kumo.com 10.3-RELEASE-p16 : Wed Feb 22 14:40:53 UTC 
2017  amd64


fb10-cc03# ipfw pipe 11 config mask dst-ip 0x00ff/0x0fff bw 200Kbit/s

fb10-cc03# ipfw pipe show
00011: 200.000 Kbit/s0 ms burst 0
q131083  50 sl. 0 flows (1 buckets) sched 65547 weight 0 lmax 0 pri 0 
droptail

 sched 65547 type FIFO flags 0x1 64 buckets 0 active
mask:  0x00 0x/0x -> 0x00ff/0x

___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

Re: How to use IPFW to filter routing

[Julian Elischer]

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 plucking out and reformatting a few bits.

  > Am 29.01.2017 um 17:40 schrieb Thomás :
  > > Have you tried something like this?
  > >
  > > ipfw add deny tcp 10.10.30.0/24 to 10.10.10.0/24 setup keep-state
  > > ipfw add deny tcp 10.10.30.0/24 to 10.10.20.0/24 setup keep-state
  > > ipfw add allow tcp 10.10.30.0/24 to any 80 setup keep-state

  > This will work. But for any new subnet Iÿÿll have to remember to deny
  > it for any other subnets. I think this can become unhandy very soon.

Thomás mentioned in passing, but I'll emphasise: this is a classic job
for tables.  Then you can add or delete entries, on the fly if needed,
and table lookups are faster than traversing multiple rules.

   ipfw deny tcp 10.10.30.0/24 to "table($deniednets)" setup

(keep-state doesn't make sense on deny rules)

  > If I try the follwing the packets are all rejected. I think the
  > inspection is done before the routing, so IPFW does not know it
  > should be forwarded using igb2.
  > ipfw add allow tcp 10.10.30.0/24 to any 80 out via igb2 setup keep-state

It's essential to get a picture in your head from ipfw(8) /PACKET FLOW

On the 'in' pass, as you later guessed, it is not known which interface
might be chosen by routing, which occurs only AFTER the inbound packet
has been accepted and is determined to be non-local .. so you have to
then do this sort of discrimination on the 'out' pass.

As Thomás suggested, add 'log' to any rule you're not sure about how or
whether they're doing the right thing, setting logamount to default 100.
Once things are working right you can lose the extra logging, but it
often makes obvious some possibly mysterious problems.

  > I also tried it using recv and xmit rules.
  > First I tried:
  >  ipfw add allow tcp from 10.10.30.0/24 to any out recv igb0.30 xmit igb2 
setup keep-state
  > it does not work.
  > and later I tried this
  >  ipfw add allow tcp from 10.10.30.0/24 to any out xmit igb2 setup keep-state
  > also not working

  > Anytime it was caught by my default rule at the end:
  >  00150 deny log logamount 5 ip from any to any

Yes, that's because you have not accepted these packets on their inbound
pass, so they fell through to the deny all rule.  The above rules cannot
work inbound, but should on the outbound pass, the form of the first one
being particularly useful.  It may be helpful showing the whole ruleset,
or at least a section in context, if you're still having issues?

  > /var/log/security said:
  >
  >  150 Deny TCP 10.10.30.5:51145 82.193.243.115:80 in via igb0.30
  >
  > So to me it looks like he does not know that the packet will be
  > transmitted via igb2 at the moment it is inspected.

Exactly so; it CANNOT know what routing will do with it, as routing only
occurs after it has been accepted, just prior to ipfw's outbound pass.



I will add that I find the following scheme works for me to help 
understand what is going on:

on a system with two interfaces $INSIDE and $OUTSIDE

I always start my rule sets with somethign like:

100 skipto 1000 ip from any to any  in recv $OUTSIDE
110 skipto 2000 ip from any to any out xmit $OUTSIDE
120 skipto 3000 ip from any to any in $INSIDE
130 skipto 4000 ip from any to any out xmit $INSIDE
140rules for localhost etc.


this gives you   clear idea of what packet are hitting which rules.
you will notice for example that an outgoing packet that is routed 
form an inside machine first does the rules at 3000 and then the rules 
at 2000



Thomás' advice re not being shy about using more deny rules is sound;
even on slow processors the time cost per rule is miniscule compared to
transmission time, unless you're pushing mega PPS over high Mbps links,
in which case you'd be using tables for the utmost advantage anyway.

cheers, Ian
___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"




___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

Re: Ipfw+dummynet on Windows 10

[Julian Elischer]

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 have popped up by now.
I think they did the windows compat stuff for some of their projects.
I've CC'd luigi.  maybe he can help.
Nobody here runs it on Windows so we can't really help you.



On Thursday, November 24, 2016, Odhiambo Washington 
wrote:


FreeBSD Team actually include ipfw team, BUT as long as you see ipfw
included in a version of FreeBSD, then it's been tested and certified as
"works". That does not mean they also test and ensure it works on Windows
as M$ continues to change/break things :-)

On 24 November 2016 at 19:33, Srikanth Reddy > wrote:


Hi Ernie,
Thank you very much.
You are right, I was in the assumption that Freebsd team include Ipfw
team.
Hence wrote the email to this community as I badly need windows 10
support.

It will be a great help if you can provide ipfw developer contact
information.

Thanks and Regards,
Srikanth.

On Thursday, November 24, 2016, Ernie Luzar > wrote:


Srikanth Reddy wrote:


On Fri, Oct 28, 2016 at 10:11 PM, Ian Smith 

>> wrote:

 freebsd-ipfw@freebsd.org

 >



​Hello All,
We couldn't find the right piece of code to change to achieve Windows

10

compatibility of ipfw.
Could any one of you can help us on ​this part?since we used ipfw in

one

of my research project its very critical for us to achieve ipfw
compatibility on windows 10 as it was working fine in windows 7

machines

without any issues.we are Ok to pay some money ( if that is not going

to

cost so much ) as you need to spend some effort to go though your code
again.

Buts its our humble request to all of you.

Thanks & Regards,
Srikanth.



Hello Srikanth.

I think you are barking up the wrong tree here. What you need is a

person

who is experienced in win10 internals not Freebsd. Even though ipfw is
maintained by the freebsd ipfw project does not mean freebsd had

anything

to do with making it able to run on win7. A win programmer took the open
source ipfw code and made changes to it so it would run on win7.

You need to contact that win7 programmer who did that work and ask him

it

he is interested in upgrading his work for win10.

Some suggestions.

1. Submit a format proposal to the FreeBSD foundation to fund a project

to

perform the desired work. This option is going to take some time. Maybe

up

to a year.

2. Change your focuses from Freebsd to Microsoft. There are win10
development forums where you can ask for help and advice. Maybe you can
find the support you want there.

Good Luck















___
freebsd-questi...@freebsd.org
 mailing
list
https://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscribe
@freebsd.org

"




--
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft."


___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"




___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

Re: change packets with IPFW divert

[Julian Elischer]

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  wrote:


On Tue, 18 Oct 2016 14:21:50 +, Shawn Bakhtiar wrote:
  > On Oct 18, 2016, at 6:49 AM, Samira Nazari > wrote:
  > > Hello every one,
  > > When we diverte packets to the specified port with "IPFW divert" ,
  > > we can change it and re-sent to the kernel?

  > Not sure what you mean by change it but:
  >
  > "Divert sockets are similar to raw IP sockets, except that they can
  > be bound to a specific divert port via the bind(2) system call.  The
  > IP address in the bind is ignored; only the port number is
  > significant.  A divert socket bound to a divert port will receive all
  > packets diverted to that port by some (here unspecified) kernel
  > mechanism(s).  Packets may also be written to a divert port, in which
  > case they re-enter kernel IP packet processing."
  >
  > -- SRC: https://www.freebsd.org/cgi/man.cgi?query=divert=
4=0=FreeBSD+10.3-RELEASE+and+Ports

Apart from divert(4), most likely the best example is the natd(8) code,
which modifies packet source or destination addresses and (maybe) ports.

Ignoring the NAT processing - or not, as appropriate - the way natd uses
divert sockets both to receive packets from ipfw and later (perhaps) to
reinject them for further processing should show clearly how it's done.

cheers, Ian


___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"



___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

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

[Julian Elischer]

Hi Bill,

On 15/09/2016 9:48 PM, Bill Yuan wrote:
In Ipfw3, each table entry has its own counter and last hit 
timestamp for both directions.


I suspect you are confusing tables and dynamic rules? (your comment 
about 'direction')


if not, can you give examples?




On 12 September 2016 at 12: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 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 thing you can do is throw away all the entries at
some time, and
 > force them to all log in again.
 >
 > Does anyone have any patches to add "access time" to table
entries?
 >
 >
 > I'm guessing the way it would need to be done now would be to
use dynamic
 > rules and having the syn packet of every tcp session sent to
the portal for
 > approval, before being passed back to create the dynamic rule.

Well nothing like patches, and surely not what you want, but
I've been
using the below since '08 to add timestamps to entries, and a
couple of
related scripts to list entries for particular tables in date
order etc.
I never finished adding the 'purge before somedate' script ..

Nowadays with multiple table values you could maybe have useful
tablearg
values like skipto targets as well.

cheers, Ian

#!/bin/sh
# addr_to_table 24/11/8 smithi
# add ipaddr[/masklen|32] and value (seconds from epoch) to table N
# 31/12/9 CIDR matching for updates, (ab)using table 0 for calc
# 4/4/11 prefer direct ipaddr/masklen format, add numeric check
usage() {
[ "$1" ] && echo $1
echo "usage: `basename $0` table address[/masklen | [
masklen]]"
exit 1
}
validint() {# value min max
[ "`echo $1 | tr -d 0-9`" ] && return 1 # not all numeric
[ $1 -ge $2 -a $1 -le $3 ] && return 0 || return 1
}
[ "$2" ] || usage
table=$1 ; addr=$2
`validint $table 1 127` || usage "table '$table' not 1..127"
[ "$3" ] && mlen=$3 || mlen=32  # allow old but prefer CIDR format
[ "${addr%/*}" != "$addr" ] && mlen=${addr#*/} && addr=${addr%/*}
`validint $mlen 8 32` || usage "masklen '$mlen' not 8..32"

addr=$addr/$mlen
if [ $mlen -lt 32 ]; then   # calc CIDR netblock addr using
table 0
ipfw -q table 0 flush ; ipfw -q table 0 add $addr
addr=`ipfw table 0 list | awk '{print $1}'`
fi  # only needed if looking up
addr/mask

ipfw -q table $table add $addr `date "+%s"` 2>/dev/null
[ $? -eq 0 ] || echo "table $table add $addr `date +%s` failed:
dupe?"
exit 0
___
freebsd-ipfw@freebsd.org <mailto:freebsd-ipfw@freebsd.org>
mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
<https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw>
To unsubscribe, send any mail to
"freebsd-ipfw-unsubscr...@freebsd.org
<mailto:freebsd-ipfw-unsubscr...@freebsd.org>"




___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

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

[Julian Elischer]

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 to time them out 
when they go idle. The omly thing you can do is throw away all the 
entries at some time, and force them to all log in again.


Does anyone have any patches to add "access time" to table entries?


I'm guessing the way it would need to be done now would be to use 
dynamic rules and having the syn packet of every session sent to



no takers?


___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

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

[Julian Elischer]

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 thing you can do is throw away all the 
entries at some time, and force them to all log in again.


Does anyone have any patches to add "access time" to table entries?


I'm guessing the way it would need to be done now would be to use 
dynamic rules and having the syn packet of every tcp session sent to 
the portal for approval, before being passed back to create the 
dynamic rule.



___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

Re: Notice on upcoming ipdbtools 1.1.1

[Julian Elischer]

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 systems, and which was used for IPv6 computing.

In the meantime, I rolled in the necessary uint128 comparison, shift and basic 
arithmetic operations that provide the missing built-in __uint128_t operations 
on 32bit systems. The 64bit targets x86-64 and arm64 continue to utilize the 
built-in operations.

The changes are ready on GitHub, and I will submit a changed port PR on Monday 
(tomorrow) night, most of the post-mortem fixes since the initial release are 
included -- I won't rename the tool 'ipup', though.

I just submitted the PR for updating the port of ipdbtools to v1.1.1.


great, when it happens I will try some analytics to see where my 
traffic is coming from.. (my gateway is i386)




https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211881

Best regards

Rolf
___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"



___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

Re: your thoughts on a particualar ipfw action.

[Julian Elischer]

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 just submitted a PR asking to add the new port 'sysutils/ipdbtools'.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211744

Wonderful.

The port maintainers were really quick. The port has been accepted
and has been already committed.

So it has, on refreshing the page.  Smooth and fast.

Re __uint128_t I _guess_ there may be macro/s to do that maths for i386?

Yeah, I am exploring the options. Comparisons, addition and subtraction are 
working already, multiplication, division and remainder operations are a tad 
more difficult, I must leave this for some weekend.


...
A more tech-savvy article than ABC or other news media managed so far:
https://www.theguardian.com/australia-news/2016/aug/10/computer-says-no-australian-census-shambles-explanation-depends-on-who-you-ask

Well, I tend to believe that this has nothing to do with DoS attacks,

Some should have been expected, planned for, mitigation anticipated, as
well as expecting at least 5 times the legit connections/hr they tested
for, and as the guardian article pointed to, their DNS was screwed in
several ways: way too long TTL (can't move fast), hard-coded subdomain
in SSL cert (couldn't readily add load-sharing capacity?) and such.

But they admit the geo-blocking fell over - whether inline as firewall
or on another server fielding lookup requests not disclosed - but they
say that failure caused a/the/some router to fail (crash? explode? :)

Perhaps they did Geo-blocking in the way that I mentioned in the summary of the 
ipdbtool's manual to be a no-go:

...
Unfortunately, online database look-up is by far too slow for even think-
ing about being utilized on the firewall level, where IP packets need to
be processed in a microsecond time scale. Therefore, a locally maintained
IP Geo-location database is indispensable in the given respect.
...


IBM, FFS! but they'll point to govt specs and disclaim hardware failure
but still it's not great product endorsement for their SoftLayer Cloud.

Natural but non-professional reaction. My mother always told us, if you point
with your index finger to others, three fingers are pointing back to you.
So IBM not only failed technically but also the PR devision did a bad job.


I mean, of course it is DoS, but not caused by an attack. Exactly the
same happens every year on 30th of April between 17:00 and 24:00 on
the servers of the Federal Bureau of Finance here in Brazil. That is
the deadline for the online-submission of the annual tax declaration
of the Brazilian citizens. Seems that the bureaucrats all over the
world share the same deficiency of creative problem solving.

Seems it's a requirement for the job, world wide.  Creativity is scary,
but you think they could guess that ~8 million households in the eastern
timezone were going to have dinner then do their census within ~2 hours.

Of course they could not guess this, because public servants are trained
to assume that the normal citizen does not meet her/his obligations, and
for sure they were (are) prepared to send out 8 million penalty notices
in 24 hours.

Actually we have until mid September to lodge the information, but if you
forget who was at you rplace that evening (guests?) then it makes sense to
do it earlier rather than later.

Who in the bureaucrats hell told them to go with one deadline for
everybody? For the census in Australia, I would have told the
citizens that everybody got an individual deadline which is his or
her birthday in 2016 -- problem solved.


see above..  it's a 6 week window from memory.



That'd be great load-balancing .. shall I let them know? :)

Doesn't cost anything giving it a try, however, you could as well slap an
ox on his horn - same effect.

___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"



___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

Re: your thoughts on a particualar ipfw action.

[Julian Elischer]

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: https://cyclaero.github.io/ipdb/, and I added 
the recent suggestions on rule number/action code per country code, namely, I changed the 
formula for the x-flag to the suggestion of Ian (value = offset + ((C1 - 'A')*26 + (C2 - 
'A'))*10), and I added the idea of directly assigning a number to a country code in the 
argument for the t-flag ("CC=n:...").

Furthermore, I removed the divert filter daemon from the Makefile. The source 
is still on GitHub, though, and can be re-vamped if necessary.

Now I am going to prepare the Makefile for the port.

I just submitted a PR asking to add the new port 'sysutils/ipdbtools'.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211744

I needed to change the name of the geoip tool, because GeoIP® is a registered 
trademark of MaxMind, Inc., see www.maxmind.com. The name of the tool is now 
'ipup' = abbreviated form of  IP  geo location table generation and look- UP , 
that is without the boring middle part :-D
Hmm I'd have gone for geotable. ipup sounds like a young dog produced 
by Apple.

(wonder if one can change the name of a port)



Those, who used geoip already in some scripts, please excuse the inconvenience 
of needing to change the name.

With the great help of Julian, I was able to improve the man file and the 
latest version can be read online:

https://cyclaero.github.io/ipdb/

Best regards

Rolf

___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"




___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

Re: your thoughts on a particualar ipfw action.

[Julian Elischer]

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 to

cope with unexpected ambiguities and mismatches.


___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

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

[Julian Elischer]

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 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-state
  > > > 21 skipto 400 tcp from table(2) to me setup
  > > > to make the entire session do the same thing.

  > > So, in your example what wrong with just using keep-state?
  > > "record-state without immediate action" == "keep-state without implicit
  > > check-state" needed to solve issues with NAT or something similar, that
  > > was described by Lev.
  > >

  > because keep-state is a check-state for ALL packets going past, regardless 
of
  > whether they match the pattern.
  >
  > at least that's what I have observed.

Except now(?) with named states/flows/whatever, isn't it the case that
check-state [flowname] only affects packets with same state/flowname? So
you can clearly separate, say, packets on different interfaces, packets
coming or going on any interface, and such?

If I'm understanding that right - quite possibly not! - then only those
packets will match, and others with other names (including 'default')
won't match states with that name.  I'm not sure I'm expressing this at
all well, because I'm only just starting to get any sort of grip, but
I'm liking the idea and wondering if it's sufficient for starters.

we  not quite..
Only the given state table will be looked at, but all packets will 
still be matched with it.




To me, orthogonality implies the least number of commands/instructions
that will accomplish the desired functionality.  First, let's find out
what can and cannot be accomplished with named states/flows .. I'm yet
to understand what record-state-without-action can accomplish apart from
that .. it could work only for the first packet I suppose, since once
state is established, further packets will match and follow state, no?

Again, I find concrete examples - like the use of valtype skipto,fib
mentioned above - really helpful, essential really, for bears of such
little brain as I ..
ok, so sometimes I like to do some processing on a packet (e.g. divert 
it somewhere for munging) after I've set up a state for it.
so I don't want to necessarily Act on the state immediately.  but the 
packet may get changed in the munging, so I need to set the state 
before hand., or I can't match it.


here's a real example that I couldn't do because I couldn't
store  a state without actually doing it.
I wanted all packets from a process on the local machine (identified 
because

it has a unique group, used for just this purpose) to be forwarded to a
particular other machine for "vetting',  however the machine I am doing
this has outgoing NAT using a modified natd that also does some added 
"stuff".
After the NAT I can no longer recognise the packets that came from 
that process
as they moved out of the kernel to userland and back, yet I still need 
these

ackets to go through the natd.
So I need to identify them first, before the nat in order to set a 
state entry for
them.   Since they are local packets NAT will not have changed their 
addresses,
so  AFTER the NAT I could have done the associated check-state which 
triggers

the stored  action (forwarding to another location).

I ended up having to do this via an ugly use of skiptos where packets
I wanted to forward, were identified early and then sent to a 
duplicate set of
rules which also did the divert,  but then did the forward. I think 
there were

about 25 rules duplicated.

Having said that, "store without do" is the least important of the 
features.

Store (do or not) without a prior checkstate is more important to me.

state name are a wonderful addition that I have yet to use in all my 
scripts

I just haven't had time yet.



cheers, Ian



___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

Re: your thoughts on a particualar ipfw action.

[Julian Elischer]

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...@freebsd.org>:

'scuse savage reformatting, but I had to wrap it to read it .. and pine
has completely mangled the quoting levels too, dunno why.


looking for thoughts from people who know the new IPFW features well..

That's not me, but I'm having fun reading 11.0-RELEASE ipfw(8) ..


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 was thinking how to use this, and the obvious way would be to
have a set of rules for each country, and use the "skipto tablearg"
facility to skip to the right rules for each country. But the
trouble is that a tablearg skipto is very inefficient. It's also a
hard thing to set up with a set of rules for each country (how many
countries are there in the internet allocation system?).

Julian, have you looked into Andrey's LINEAR_SKIPTO ?  How does it work?
Are there any disadvantages?  And if not, why isn't it the default? :)

no, until he mentioned i I was unaware of it..
I will be looking at it as soon as 1 have time.


Also, There's a particularly useful example in new ipfw(8), showing how
to set and use multiple tablearg values - the example uses skipto,fib
with a setfib tablearg followed by a skipto tablearg both from the same
table entry, and you can use, among others - some fully documented, some
yet to catch up - dscp values (0..63) setting or testing, and notably
tags 1..65534, set or test, which goes some way towards 'variables' you
were hoping for, no? :)  Also some netgraph stuff I won't understand ..
tags "almost" do variables but  they stick on the packet after it 
leaves ipfw and may cause misinterpretation if the packet enters ipfw 
a second time. It's a question of scope.





As of today a total of 236 country codes are in use for IPv4

delegations. If this helps for anything, a command line switch to the
geoip tool could be added for letting it output the country code (as the
hex encoded CC taken as a plain decimal integer) as the value for the
given table entry. In the moment you can give one value for all entries
generated by geoip, with this switch set, the output of geoip could look
like:


$ geoip -t "DE:BR:US" -x
...
table 0 add 93.157.48.0/21 4445
table 0 add 93.158.236.0/22 4252
table 0 add 93.159.96.0/19 4445
table 0 add 93.159.248.0/21 4445
table 0 add 93.180.72.0/21 4445
table 0 add 93.180.152.0/21 4445
table 0 add 93.181.0.0/18 4445
table 0 add 93.183.0.0/18 5553
...

Given that ...
0x4445 = 'DE'
0x4252 = 'BR'
0x5553 = 'US'

well it would have to be the decimal value so DE would be 6869, as
while 4445 works 444F is a problem :-)

RJ> Yes, you're right, I was taken away by the wave of enthusiasm,
RJ> before thinking about the subject up to the end.


0x444F would work but we waste even more address space.  You'd have to

multiply the numbers by some scaler, because adjacent numbers would not
be enough for one rule to do something and another rule to skip on to
somewhere else. (well, you could have multiple rules at the same number
but that has its limitations. > The idea would certainly work. it would
mean setting aside all the rules between 6565 and 9090 however. > A more
compact encoding could be something like


((name[0]-'A') * 32)+(name[1]-'A')) multiplied by some 'step' (maybe
10 by default) and offset by a given offset.
so AF (Afghanistan) would be the first 0*32+5 * 10 would give an
offset of 50.. plus a user supplied offset turns it into say, 15050..

RJ> I understand the reasons, however, any complicated encoding will
defeat the idea of the value can be sort of numeric mnemonic for the
country code ÿÿ well, so it is. I elaborated on your idea and came-up
with the following formula:  val = (C1-60)*1000 + C2*10 + offset. The
offset can be given as the parameter to the -x flag.

$ geoip -t "DE:BR:US" -4 -x 3
...
table 0 add 93.157.48.0/21 38690
table 0 add 93.158.236.0/22 36820
table 0 add 93.159.96.0/19 38690
table 0 add 93.159.248.0/21 38690
table 0 add 93.180.72.0/21 38690
table 0 add 93.180.152.0/21 38690
table 0 add 93.181.0.0/18 38690
table 0 add 93.183.0.0/18 55830
...

The limits (without offset) are:
AA = 5650  -- actually AD = 5680
ZZ = 30900

RJ> With this formula, the offset must be less than 34735. Although,
this wastes a considerable amount of rule number space, the advantage is
that the numbers are still accessible by mental arithmetic, and the
other constraint of having a step > 1 is fulfilled as well. Anyway, this
one is not graved in stone, we can agree on another one.

Sorry, but that encoding takes up 

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

[Julian Elischer]

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 expected when you have created this
rule :)


yes that's what I was thinking..

I'm guessing that the table is not evaluated due to the dynamic match 
and thus the skipto fails, either doing nothing, or dropping the 
packet (not sure which)



___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

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

[Julian Elischer]

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 skipto 400 tcp from table(2) to me setup record-state
21 skipto 400 tcp from table(2) to me setup
to make the entire session do the same thing.

  Sometimes it could be

20 skipto 400 tcp from table(2) to me setup record-state
21 check-state

  But only sometimes.


exactly.. I don't want OTHER packets coming past here to hit a 
check-state yet.. I still have unfinished business with them.






___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

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

[Julian Elischer]

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-state
21 skipto 400 tcp from table(2) to me setup
to make the entire session do the same thing.

So, in your example what wrong with just using keep-state?
"record-state without immediate action" == "keep-state without implicit
check-state" needed to solve issues with NAT or something similar, that
was described by Lev.

because keep-state is a check-state for ALL packets going past, 
regardless of whether they match the pattern.


at least that's what I have observed.



___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

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

[Julian Elischer]

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 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 < less 
important

for me.
So, if there are nobody against, I plan to commit this part in a 
several

days.

  Which implementation? Just curious, I could live with any, really.

This one
https://people.freebsd.org/~ae/ipfw.diff

but with separate opcodes, I  have come to the opinion, that this will
be more readable.

so, reading it. it appears that teh record-state saves a rule as a 
target but doesn't actually perform the rule, right?


that needs to be made more clear in the man page

you say " Instead, the firewall creates a dynamic rule and the 
search continues with the next rule."


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-state

21 skipto 400 tcp from table(2) to me setup

to make the entire session do the same thing.





___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"



___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

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

[Julian Elischer]

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 < less important
for me.

So, if there are nobody against, I plan to commit this part in a several
days.

  Which implementation? Just curious, I could live with any, really.

This one
https://people.freebsd.org/~ae/ipfw.diff

but with separate opcodes, I  have come to the opinion, that this will
be more readable.

so, reading it. it appears that teh record-state saves a rule as a 
target but doesn't actually perform the rule, right?


that needs to be made more clear in the man page

you say " Instead, the firewall creates a dynamic rule and the search 
continues with the next rule."


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-state

21 skipto 400 tcp from table(2) to me setup

to make the entire session do the same thing.





___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

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

[Julian Elischer]

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) is orthogonal to (3) and it should
be different change sets, reviews, etc. And, yes, (3) is great feature
by itself.
I think 1 on its own would have  good chance.. I'd probably commit it 
myself :-)

save-state  as a new keyword, that doesn't do a check-state.

2 is more esoteric. and sort of orthogonal to 1.




Do we have any movement on these improvements?
even similar functionality by different names is ok.

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 < less important
for me.
3/ multiple state tables? this was discussed and I thought I saw patches
but I haven't seen it going in,  <-- super luxurious

just noticed this IS in...



___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

Re: your thoughts on a particualar ipfw action.

[Julian Elischer]

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 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 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 was thinking how to use this, and the obvious way would be to have a set of rules 
for each country, and use the "skipto tablearg" facility to skip to the right 
rules for each country. But the trouble is that a tablearg skipto is very inefficient. 
It's also a hard thing to set up with a set of rules for each country (how many countries 
are there in the internet allocation system?).

As of today a total of 236 country codes are in use for IPv4 delegations. If 
this helps for anything, a command line switch to the geoip tool could be added 
for letting it output the country code (as the hex encoded CC taken as a plain 
decimal integer) as the value for the given table entry. In the moment you can 
give one value for all entries generated by geoip, with this switch set, the 
output of geoip could look like:

$ geoip -t "DE:BR:US" -x
...
table 0 add 93.157.48.0/21 4445
table 0 add 93.158.236.0/22 4252
table 0 add 93.159.96.0/19 4445
table 0 add 93.159.248.0/21 4445
table 0 add 93.180.72.0/21 4445
table 0 add 93.180.152.0/21 4445
table 0 add 93.181.0.0/18 4445
table 0 add 93.183.0.0/18 5553
...

Given that ...
0x4445 = 'DE'
0x4252 = 'BR'
0x5553 = 'US'

well it would have to be the decimal value so DE would be 6869, as while 4445 
works 444F is a problem :-)

Yes, you're right, I was taken away by the wave of enthusiasm, before thinking 
about the subject up to the end.


0x444F would work but we waste even more address space.  You'd have to multiply 
the numbers by some scaler, because adjacent numbers would not be enough for 
one rule to do something and another rule to skip on to somewhere else. (well, 
you could have multiple rules at the same number but that has its limitations.
The idea would certainly work. it would mean setting aside all  the rules  
between 6565 and 9090 however.
A more compact encoding could be something like ((name[0]-'A') * 
32)+(name[1]-'A')) multiplied by some 'step' (maybe 10 by default) and offset 
by a given offset.

so AF (Afghanistan) would be the first 0*32+5  * 10 would give an offset of 
50.. plus a user supplied offset turns it into say, 15050..

I understand the reasons, however, any complicated encoding will defeat the 
idea of the value can be sort of numeric mnemonic for the country code – well, 
so it is. I elaborated on your idea and came-up with the following formula:  
val = (C1-60)*1000 + C2*10 + offset. The offset can be given as the parameter 
to the -x flag.

$ geoip -t "DE:BR:US" -4 -x 3
...
table 0 add 93.157.48.0/21 38690
table 0 add 93.158.236.0/22 36820
table 0 add 93.159.96.0/19 38690
table 0 add 93.159.248.0/21 38690
table 0 add 93.180.72.0/21 38690
table 0 add 93.180.152.0/21 38690
table 0 add 93.181.0.0/18 38690
table 0 add 93.183.0.0/18 55830
...

The limits (without offset) are:
AA = 5650  -- actually AD = 5680
ZZ = 30900

With this formula, the offset must be less than 34735. Although, this wastes a 
considerable amount of rule number space, the advantage is that the numbers are 
still accessible by mental arithmetic, and the other constraint of having a step 
> 1 is fulfilled as well. Anyway, this one is not graved in stone, we can agree 
on another one.


or there could be a translation into iso3166 numeric codes where Afghanistan is 
004, but then you have the worry of keeping the data up to date as they add new 
country codes, which in my opinion makes it a bad solution.

Agreed, too much dependencies, let's forget the numeric iso codes.


BTW: The ipdb tools are now IPv6 aware.

$ geoip 2001:1900:2254:206a::50:5
2001:1900:2254:206a::50:5 in 2001:1900:0:0:0:0:0:0 - 
2001:1900:::::: in US

$ geoip -t "DE:BR:US" -p
...
...
217.194.64.0/20
217.194.224.0/20
217.195.0.0/20
217.195.32.0/20
217.197.80.0/20
217.198.128.0/20
217.198.240.0/20
217.199.64.0/20
217.199.192.0/20
217.224.0.0/11
2001:400:0:0:0:0:0:0/32
2001:408:0:0:0:0:0:0/32
2001:418:0:0:0:0:0:0/32
2001:420:0:0:0:0:0:0/32
2001:428:0:0:0:0:0:0/32
2001:430:0:0:0:0:0:0/32
2001:438:0:0:0:0:0:0/32
...
...

$ geoip -t "" -p | wc -l
   137097

For processing only IPv4 addresses, add the -4 switch (this reproduces the old 
behaviour)
$ geoip -4 -t "" -p | wc -l
   106637

For processing only IPv6 addresses, add the -6 switch
$ geoip -6 -t "" -p | wc -l
30460

10

Re: your thoughts on a particualar ipfw action.

[Julian Elischer]

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 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 was thinking how to use this, and the obvious way would be to have a set of rules 
for each country, and use the "skipto tablearg" facility to skip to the right 
rules for each country. But the trouble is that a tablearg skipto is very inefficient. 
It's also a hard thing to set up with a set of rules for each country (how many countries 
are there in the internet allocation system?).

As of today a total of 236 country codes are in use for IPv4 delegations. If 
this helps for anything, a command line switch to the geoip tool could be added 
for letting it output the country code (as the hex encoded CC taken as a plain 
decimal integer) as the value for the given table entry. In the moment you can 
give one value for all entries generated by geoip, with this switch set, the 
output of geoip could look like:

$ geoip -t "DE:BR:US" -x
...
table 0 add 93.157.48.0/21 4445
table 0 add 93.158.236.0/22 4252
table 0 add 93.159.96.0/19 4445
table 0 add 93.159.248.0/21 4445
table 0 add 93.180.72.0/21 4445
table 0 add 93.180.152.0/21 4445
table 0 add 93.181.0.0/18 4445
table 0 add 93.183.0.0/18 5553
...

Given that ...
0x4445 = 'DE'
0x4252 = 'BR'
0x5553 = 'US'
well it would have to be the decimal value so DE would be 6869, as 
while 4445 works 444F is a problem :-)
0x444F would work but we waste even more address space.  You'd have to 
multiply the numbers by some scaler, because adjacent numbers would 
not be enough for one rule to do something and another rule to skip on 
to somewhere else. (well, you could have multiple rules at the same 
number but that has its limitations.
The idea would certainly work. it would mean setting aside all  the 
rules  between 6565 and 9090 however.
A more compact encoding could be something like ((name[0]-'A') * 
32)+(name[1]-'A')) multiplied by some 'step' (maybe 10 by default) and 
offset by a given offset.


so AF (Afghanistan) would be the first 0*32+5  * 10 would give an 
offset of 50.. plus a user supplied offset turns it into say, 15050..


or there could be a translation into iso3166 numeric codes where 
Afghanistan is 004, but then you have the worry of keeping the data up 
to date as they add new country codes, which in my opinion makes it a 
bad solution.


..., IT people who know by heart the low ASCII table like chemists (are 
supposed to) know the periodic table of the elements, this should be not too 
hard to remember.

true



Another way would be to just put 'action numbers' in the tablearg field and 
have a few actions, shared by countries, but the trouble comes when you want to 
 change the action for  a country, you need to rewrite potentially thousands of 
entries (USA has over 15800 allocations).

Two or more geoip commands can be used for populating ipfw tables for different 
utilization in ipfw directives:

# Europe
geoip -t "FR:IT:DE:NL:BE:GB:..." -n 1 -x | ipfw -q > /dev/stdin

# North America
geoip -t "US:CA" -n 2 -x | ipfw -q > /dev/stdin

# South America
geoip -t "AR:BR:UR:CL:PY:BO:PE..." -n 3 -x | ipfw -q > /dev/stdin

...


A second way woudl be to somehow map the tablearg of the country, into a table 
of actions. effectively doing two levels of lookup.

The first table converting IP addresses to a country number and a second lookup 
converting that to an action.

the only trouble is that I don't know of a way to do that.  If the new changes 
allow that, and anyone knows how, please let me know :-).

Looking-up a given IP in the totally balanced binary search tree takes on a 
decent system on average about 10-20 nanoseconds. So in theory 50 to 100 
million packets per second could be filtered by this algorithm. In order to 
come more close to this performance in reality, it might be an option to move 
the search algorithm into ipfw.

Best regards

Rolf

___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"



___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

your thoughts on a particualar ipfw action.

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


SO I was thinking how to use this, and the obvious way would be to 
have a set of rules for each country, and use the "skipto tablearg" 
facility to skip to the right rules for each country. But the trouble 
is that a tablearg skipto is very inefficient. It's also a hard thing 
to set up with a set of rules for each country (how many countries are 
there in the internet allocation system?).


Another way would be to just put 'action numbers' in the tablearg 
field and have a few actions, shared by countries, but the trouble 
comes when you want to  change the action for  a country, you need to 
rewrite potentially thousands of entries (USA has over 15800 allocations).


A second way woudl be to somehow map the tablearg of the country, into 
a table of actions. effectively doing two levels of lookup.


The first table converting IP addresses to a country number and a 
second lookup converting that to an action.


the only trouble is that I don't know of a way to do that.  If the new 
changes allow that, and anyone knows how, please let me know :-).




___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

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

[Julian Elischer]

Do we have any movement on these improvements?
even similar functionality by different names is ok.

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 < less 
important for 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 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 solve it in a easy way wrongly using 
existing

  > > > methods.
  > >It is was initial driver for this patch, yes, but, please, 
read

  > > subject (? is mistype, of course, it is closing ").
  > >
  > >Current set of primitives, dealing with state, is terribly 
wrong,
  > > IMHO. "keep-state" which trigger (any!) state check alone is 
awuful,
  > > and complete "keep-state / check-state" pair is ugly hack. It 
is like

  > > CISC vs RISC, actually.
  > >
  > >New primitives are ORTHOGONAL. Each one solves one and 
only one

  > > well-defined task, state creation, state checking and command
  > > execution are well-separated. IMHO, "keep-state" in it 
current form

  > > should be killed with fire. Yes, I understand about backward
  > > compatibility and POLA, so I don't propose to really remove 
it, but,

  > > IMHO, new set is much, much better.

Lev, is there any chance you and Andrey can work together here? At the
moment we seem to have two 'competing' models.  Can they be melded at
all?  Or can you live with adding new opcodes on top of Andrey's named
states?  (Feel free to tell me that this is none of my business ..)

yes, please..

  > In writing complicated automatically generated firewalls,
  > I've wanted the following capacities:
  > 1/ one state table for one part of the flow and another for a 
different
  > part...  e.g. a different table for "inside" nat to "outside" 
nat..


Isn't one table with distinct flow-or-whatever names for matching not
sufficient for this purpose?  Wouldn't that also be faster than having
to consult multiple distinct tables?
if you name table entries then you effectively have different 
tables, but yes I was mistaken in how it was being done.

I had assumed a separate table


In the end those are details the user doesn't need to know about .. 
but

ze does need to comprehend the terms conveying the ideas.

  > also a different table for the inside interface to the outside 
interface..
  > just because you allow a flow at one interface doesn't mean you 
want it to be

  > allowed through a different one.

Sure, so couldn't you have, say, 'inbound_outside', 'inbound_inside',
'outbound_outside' and 'outbound_inside', 'from_dmz' or whatever to
distinguish multiple flows?

Why doesn't 'flowname' sound right to describe what you call 'flows'?

multiple flows can end up in the same table/name
a flow to me is some set of packets that relate to each other in 
source,
destination and sequence.  you could almost say that each pair of 
sockets defines a flow.
Others probably have different definitions.. One could even say that 
in the context of
ipfw, any set of packets that can be discriminated by a set of rules 
can be a flow.


  > 2/ The ability to  specifically add a flow's state rule to a 
table, without
  > EVERY OTHER FLOW hitting a 'check-state' at that point. If I 
select s
  > particular flow , then I do not want other flows affected. just 
that flow

  > should be affected.

Isn't that the case with Andrey's code at the moment, if you specify a
name on that keep-state rule, only that - erm - flow would be checked
and not other flows (including 'default' where added by unnamed 
rules)?

no. but it is the case with Lev's patch (and Andrey's matching effort)


Can I assume that if this is the first keep-state|limit for one 
flowname

then an implicit check-state would check that flow only, finding none?
I don't know.  currently the selector part of the rule doesn't 
distinguish who does a check-state.

I'm guessing he finds the label and uses it but I don't know.



Similarly, if I'm grokking this at all right, then only a check-state
(or another keep-state or limit encountered) with that same name will
match existing states having that same name?  Issue 2/ solved or not?


Issue 2 is mostly solved for man

Re: ipfw divert filter for IPv4 geo-blocking

[Julian Elischer]

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 start and end address of an IP 
block given by the delegation files MUST BE PRESERVED during the transformation 
to a set of CIDR records. This target is achieved by:

  1. Finding the largest common netmask boundary of the start address utilizing
 int(log2(addr_count)); then iteration like Euclid's algorithm in computing
 a GCD.

  2. Output the CIDR with the given start address and the masklen belonging
 to the found netmask.

  3. If the CIDR does not match the whole original IP range then set the start
 address of the next CIDR block to the next boundary of the common netmask,
 and loop over starting at 1. until the original range has been satisfied.


check out the appletalk code I pointed out  to you.. I wrote that in 93 or so 
but I remember sweating blood
over it to get it right.

I read the description of the code and the following sentence made me suspicious that 
aa_dorangeroute() would guarantee the above mentioned main constraint  "start and 
end address of an IP block given by the delegation files MUST BE PRESERVED" can be 
matched. Start/end address are said to be anything (even undefined) but fixed in the 
description

So you get your data as ranges (i.e. a start and an end address)


...
Split the range into two subranges such that the middle
of the two ranges is the point where the highest bit of difference
between the two addresses makes its transition.
...

I do not want this.

I think I may explain it better by example..

Any range of addresses can conceptually be broken into an optimal 
range of binary chunks.
for example, for the range 1. 62   we have an optimal set of 
binary subranges:

 1-1  2-3  4-7 8-15 16-31 (*) 32-47 48-55 56-59 60-61 and 62-62
there is always a point (*)  where we separate the left hand side from 
the right hand side.  You can also only merge the two items either 
side of the (*) point, and even then, only if they have the same 
width. Ranges not immediately adjacent to the (*) point can never be 
merged into any other range.
In some ranges, there are no items to the right, and for some ranges 
there are no items to the left. There may also be skipped ranges. The 
above example is "worst case".  All 10 subranges are present, and only 
2 can be merged, leading to needing 9 binary subranges to correctly 
express the whole range.
So the term "middle" is misleading.  It however allows you to take an 
arbitrary range of addresses and generate the optimal set of cidr 
addresses.
In this case if you had 10.0.1.0 through 10.0.62.255 you would need 9 
cidr addresses to express the range correctly (the middle two can be 
joined).

That is what the code referred to does.

if you have exceptions as you do in routing tables,  you can express 
it as 3 cidr addresses..  0-64  MINUS 0 and MINUS 63.
i.e 10.0.0.0/18 minus 10.0.0.0/24 minus 10.0.63.0/24. However this is 
probably not of interest to your use case.
It however IS possible to do this in ipfw since it allows overlapping 
ranges of different widths. (you will note that the code pointed to 
does NOT do that. it would be an order of magnitude (or more) harder 
to do.)





I carefully tested the algorithm and a table that I pipe by the new geoip tool 
into ipfw is 100 % identical to the output of the ipfw command 'table N list'.

though that doesn't mean it is semantically identical to the original table due to 
'most specific rule wins" behaviour.

for example:
if you type in ;

1.2.3.0/24 -> A
and
1.2.3.0/26 -> B
then both rules will be listed the same as what you put in
but if you wanted to get all rules that point to A, without having rules that 
point to B, then you would have to export
1.2.3.64/26  -> A
1.2.3.128/25 -> A
  (i.e. TWO rules)

This is definitely not the usage case. The origin of the data to be passed to 
ipfw tables are RIR delegation statistics files, which is guaranteed to be 
consolidated, namely resolved overlaps and joined adjacencies, long before any 
tables for ipfw are generated. Each range entry got a well defined, i.e. fixed, 
i.e non-variable starting address, and anything that changes the starting 
address of the ranges renders the table useless. Every entry got a well defined 
range length, and that one also must not be changed, or the table would be 
useless as well.

I think you are misunderstanding what I meant.


In addition, we are talking about automatic generation of thousands of entries, 
and I never ever won't rely on something like 'most specific rule wins' 
behaviour, I want the behaviour as explicit as possible, and for this reason I 
am happy with 'INPUT is 100 % identical to the OUTPUT'.

Re: ipfw divert filter for IPv4 geo-blocking

[Julian Elischer]

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 28.07.2016 um 23:48 schrieb Lee Brown <l...@ratnaling.org>:

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)
201.222.28.0/22 (201.222.28.0-201.222.31.255)

Ian, Julian and Lee,

Thank you vary much for your responses. In order not bloat the thread, I answer 
only to one message.

I found the problem. As a matter of fact, the respective IP ranges in the 
LACNIC delegation statistics file are 3 adjacent blocks with 1024 addresses, 
i.e. those that you listed in your message above:

$grep 201.222.2 /usr/local/etc/ipdb/IPRanges/lacnic.dat
lacnic|BR|ipv4|201.222.20.0|1024|20140710|allocated|164725
lacnic|BR|ipv4|201.222.24.0|1024|20140630|allocated|138376
lacnic|BR|ipv4|201.222.28.0|1024|20140701|allocated|129095

However, my database compilation combines adjacent blocks with the same country 
code, and the ranges above turn into one block of 3072 addresses, which 
obviously doesn't have a valid netmask - log(3072) = 11,5849625.
...
..., it is not sufficient to forget about optimization but I need to check also 
whether, the delegation files contain already some non-CIDR ranges, which need 
to be broken down.

there is code to take ranges and produce cidr sets.

We used to have exactly that code in the appletalk code before we took it out. 
Appletalk uses ranges.
https://svnweb.freebsd.org/base/release/3.2.0/sys/netatalk/at_control.c?view=annotate#l703

though htat uassumes input in the form af an appletak sockaddr..
there is also this python module
https://pythonhosted.org/netaddr/tutorial_01.html#support-for-non-standard-address-ranges


maybe you can find other versions on the net.
however if you fully populate the table, you will get the correct result 
because more specific entries will
override less specific entries. To do that you would have to have a way to 
describe to your program what
value each table entry should output.
If you did what you do now, then you would specify the value for the required countries, 
and give a default falue for "all others".
aggregation of adjacent ranges with same value would be an optimisation.

Don't worry, breaking down an arbitrary IP-range into a CIDR conforming set of 
ranges, doesn't seem too difficult. ...
...
Once I come to a conclusion, I will post it to this mailing list.

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 given by the delegation files MUST BE PRESERVED during the transformation 
to a set of CIDR records. This target is achieved by:

  1. Finding the largest common netmask boundary of the start address utilizing
 int(log2(addr_count)); then iteration like Euclid's algorithm in computing
 a GCD.

  2. Output the CIDR with the given start address and the masklen belonging
 to the found netmask.

  3. If the CIDR does not match the whole original IP range then set the start
 address of the next CIDR block to the next boundary of the common netmask,
 and loop over starting at 1. until the original range has been satisfied.


check out the appletalk code I pointed out  to you.. I wrote that in 
93 or so but I remember sweating blood

over it to get it right.


I carefully tested the algorithm and a table that I pipe by the new geoip tool 
into ipfw is 100 % identical to the output of the ipfw command 'table N list'.
though that doesn't mean it is semantically identical to the original 
table due to 'most specific rule wins" behaviour.


for example:
if you type in ;

1.2.3.0/24 -> A
and
1.2.3.0/26 -> B
then both rules will be listed the same as what you put in
but if you wanted to get all rules that point to A, without having 
rules that point to B, then you would have to export

1.2.3.64/26  -> A
1.2.3.128/25 -> A
 (i.e. TWO rules)

you could also export
1.2.3.0/24 -> A
1.2.3.0/26 -> 0  (think of it as an "EXCEPT for these" rule)

which is ALSO two rules but you would need to be sure that the 
receiver knows what to do with them.




It is worth to note, that already the original RIR delegation files contain 457 
non CIDR conforming IPv4 ranges in a total of 165815 original records. I guess 
that this number will increase in the future because the RIR's ran empty on new 
IPv4 ranges and are urged to subdivide returned old ranges for new delegations. 
The above algorithm is ready for this.

Generally, CIDR conforming tables are more than twice as large as optimized 
(joined adjacencies) 

Re: ipfw divert filter for IPv4 geo-blocking

[Julian Elischer]

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 being quite relevant to system security. Or, may I assume that 
ipfw knows always better than the user what should be allowed or denied. 
Otherwise, perhaps I am the only one ever who input incorrect CIDR ranges for 
processing by ipfw.
it's not so amazing when you think about it. The code comes from the 
routing table..


In this context  a.b.c.d/N means "the range of addresses containing 
a.b.c.d, masked to a length of N".  there is no specification that 
a.b.c.d is the first address of the range.  I have relied upon this 
behaviour many times.




Best regards

Rolf

___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"



___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

Re: ipfw divert filter for IPv4 geo-blocking

[Julian Elischer]

On 29/07/2016 10:48 AM, Lee Brown wrote:

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:
whether it makes sense depends on whether you add the other ranges as 
well with  the default result.
Your daemon has the entire set loaded so it can exclude other internal 
ranges, however it looks like you have only provided

ipfw with partial information.


you'd need to add:

201.222.20.0/20  1
201.222.16.0/22  0

or more correctly what Lee showed above

either the imput data is incorrect, or your cidr aggregation  code has a bug.
because 201.222.20.0/20 (well more correctly "misleading") cidr description).
It implies 201.222.16.0/20  because if you mask 201.222.20.0 with 255.255.240.0 
 (/20) that's what you get.

observe:
soekris# route add 201.222.20.0/20 127.0.0.1
add net 201.222.20.0: gateway 127.0.0.1
soekris# netstat -rn
Routing tables

Internet:
DestinationGatewayFlagsRefs  Use  Netif Expire
default192.168.0.1UGS 0  9082198vr2
[...]
201.222.16.0/20127.0.0.1  US  00lo0
[...]

to make this work correctly you'd either need lee's answer, or you 
need to give it more information:

201.222.16.0/20  {result for brazil}
201.222.16.0/22  {default result, to get subtracted from the above.
your program give s the correct result because it has all the 
information, including the AR information

but you didn't tell ipfw about that.
I suggest you need either input data sanitization, or to fix our 
output code to give the correct subranges.

becasue 201.222.16.0/20 is definately bad input to ipfw.



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)
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, 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 addresses on the command line.

 https://github.com/cyclaero/ipdb/blob/master/geoip.c

This one could easily be extended to produce sorted IP ranges per CC

that could be fed into tables of ipfw. I am thinking of adding a command
line option for specifying CC's for which the IP ranges should be exported,
something like:

geoip -e DE:BR:US:IT:FR:ES

And this could print sorted IP-Ranges belonging to the listed

countries. For this purpose, what would be the ideal format for directly
feeding the produced output into ipfw tables?

The format for using tables directly is the same as that used for

routing tables.

…
table 5 add 1.1.1.0/32 1000
…
your application becomes an application for configuring the firewall.
(which you do by feeding commands down a pipe to ipfw, which is

started as 'ipfw -q /dev/stdin')

I finished adding a second usage form for the geoip tool, namely

generation of ipfw table construction directives filtered by country codes.

wow, wonderful!

with that tool, and ipfw tables we have a fully functional geo

blocking/munging solution in about 4 lines of shell script.

Unfortunately, I finally discovered that ipfw tables as they are, are
unsuitable for the given purpose, because for some reason ipfw mangles
about 20 % of the passed IP address/masklen pairs.

For example:

# ipfw table 1 add 201.222.20.0/20
# ipfw table 1 list
-->  201.222.16.0/20 0

$ geoip 201.222.20.1
--> 201.222.20.1 in 201.222.20.0-201.222.31.255 in BR

$ geoip 201.222.16.1
--> 201.222.16.1 in 201.222.16.0-201.222.19.255 in AR

Effectively, I asked ipfw to add an IP-range of Brazil to table 1, but it
actually added another one which belongs to Argentina. This doesn't make
too much sense, does it?

For the time being I switched my servers back to geo-blocking with the
divert filter daemon.

Best regards

Rolf

___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"




___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

Re: ipfw divert filter for IPv4 geo-blocking

[Julian Elischer]

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, where static skiptos cache the location of the
  > rule to skip to. it's not a terrible cost but it needs to be  kept in mind.
  > (but faster than a divert socket)

I forget .. is that linear search from the beginning, or from the
position of the rule querying the table?  Just thnking about grouping
skipto target rules to minimise traversal.  These targets in turn could
use static skiptos that will be cached.

it starts searching forwards from the current location, to stop loops.
(though it turns out you CAN make loops using some arcane sequences 
that I will not make public).


However divert reinjection searches from the start to get to the place 
you want to restart processing.

(but it's a very small loop) so put the diverts near the front if you can.



  > your application becomes an application for configuring the firewall.
  > (which you do by feeding commands down a pipe to ipfw, which is started as
  > 'ipfw -q /dev/stdin')

I went looking though ports for ipfw-classifyd, which attracted my
interest in 2008, but seems never to have made it to ports.  Written by
Mike Makonnen <m...@freebsd.org> (cc'd), it uses divert sockets with the
linux- based 'l7' filters for detecting traffic from a wide array of UDP
and TCP protocols, with the primary intent then of detecting various P2P
traffic and shunting it through dummynet pipes for bandwidth limiting.

I vaguely remember it.


Interesting discussion, and thanks for info on geoip tables etc.

cheers, Ian



___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

Re: ipfw divert filter for IPv4 geo-blocking

[Julian Elischer]

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 addresses on the command line.

 https://github.com/cyclaero/ipdb/blob/master/geoip.c

This one could easily be extended to produce sorted IP ranges per CC that could 
be fed into tables of ipfw. I am thinking of adding a command line option for 
specifying CC's for which the IP ranges should be exported, something like:

geoip -e DE:BR:US:IT:FR:ES

And this could print sorted IP-Ranges belonging to the listed countries. For 
this purpose, what would be the ideal format for directly feeding the produced 
output into ipfw tables?

The format for using tables directly is the same as that used for routing 
tables.
…
table 5 add 1.1.1.0/32 1000
…
your application becomes an application for configuring the firewall.
(which you do by feeding commands down a pipe to ipfw, which is started as 
'ipfw -q /dev/stdin')

I finished adding a second usage form for the geoip tool, namely generation of 
ipfw table construction directives filtered by country codes.

wow, wonderful!

with that tool, and ipfw tables we have a fully functional geo 
blocking/munging solution in about 4 lines of shell script.




__
$ geoip -h
geoip v1.0.1 (16), Copyright © 2016 Dr. Rolf Jansen

Usage:

1) look-up the country code belonging to an IPv4 address given by the last 
command line argument:

geoip [-r bstfile] [-h] 
   a dotted IPv4 address to be looked-up.

2) generate a sorted list of IPv4 address/masklen pairs per country code, 
formatted as ipfw table construction directives:

geoip -t [CC:DD:EE:..] [-n table number] [-v table value] [-r bstfile] [-h]

   -t [CC:DD:EE:..]  output all IPv4 address/masklen pairs belonging to the 
listed countries, given by 2 letter
 capital country codes, separated by colon. An empty CC 
list means any country code.
   -n table number   the ipfw table number between 0 and 65534 [default: 0].
   -v table valuethe 32-bit unsigned value of the ipfw table entry 
[default: 0].

valid arguments in both usage forms:

   -r bstfilethe path to the binary file with the consolidated IP 
ranges that has been.
 generated by the 'ipdb' tool [default: 
/usr/local/etc/ipdb/IPRanges/ipcc.bst].
   -hshow these usage instructions.
__

With that, the ipfw configuration script may contain something alike:

 …
 # allow only web access from DE, BR, US:
 /usr/local/bin/geoip -t DE:BR:US -n 7 | /sbin/ipfw -q /dev/stdin
 /sbin/ipfw -q add 70 deny tcp from not table\(7\) to any 80,443 in recv 
WAN_if setup
 …

OR, the other way around:
 …
 # deny web access from certain disgraceful regions:
 /usr/local/bin/geoip -t KO:TR:SA:RU:GB -n 66 | /sbin/ipfw -q /dev/stdin
 /sbin/ipfw -q add 70 allow tcp from not table\(66\) to any 80,443 in recv 
WAN_if setup
 …



Best regards

Rolf






___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

Re: ipfw divert filter for IPv4 geo-blocking

[Julian Elischer]

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 consolidated range/cc pairs. On 
starting-up, the divert daemon reads the binary file in one block and stores 
the ranges into a totally balanced binary search tree. Looking-up a country 
code for a given IPv4 address in the BST takes on average 20 nanoseconds on an 
AWS-EC2 micro instance. I don't know the overhead of diverting, though. I guess 
this may be one or two orders of magnitudes higher. Even though, I won't see 
any performance issues.

yes the diversion to user space is not a fast operation. When we wrote it, fast 
was 10Mbits/sec.
The firewall tables use a radix tree (*) and might be slower than what you 
have, but possibly it might be made up for by not having to do the divert 
logic. it's not entorely clear from your description why you look up  a country 
rather than just a pass/block result, but maybe different sources can access 
different countries?.

The basic idea was to develop a facility for ipfw for filtering IPv4 packets by 
country code - see: https://github.com/cyclaero/ipdb

I simply put into /etc/rc.conf:

geod_enable="YES"
geod_flags="-a DE:BR:US"

The -a flag tells, that source IP addresses only from these countries are 
allowed (i.e. passed through the filter). I added also a -d flag, which means 
deny (i.e. drop packets) from the given list of countries.

With that in place, I need to add a respective divert rule to the ipfw ruleset 
(the divert port of the geod daemon is 8669, remembering that 8668 is the port 
of the natd daemon):

 ipfw -q add 70 divert 8669 tcp from any to any 80,443 in recv WAN_if setup


I did similar once using ipfw tables but couldn't find a reliable source of 
data.

The IP/CC database is compiled from downloads of the daily published delegation 
statistics files of the 5 RIR's. I consider the RIR's being the authoritative 
source. Anyway, on my systems the IP/CC-database is updated only weekly, 
although, daily updating would be possible. I wrote a shell script for this, 
that can be executed by a cron job.

 https://github.com/cyclaero/ipdb/blob/master/ipdb-update.sh 
<https://github.com/cyclaero/ipdb/blob/master/ipdb-update.sh>

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.

 https://github.com/cyclaero/ipdb/blob/master/geoip.c

This one could easily be extended to produce sorted IP ranges per CC that could 
be fed into tables of ipfw. I am thinking of adding a command line option for 
specifying CC's for which the IP ranges should be exported, something like:

geoip -e DE:BR:US:IT:FR:ES

And this could print sorted IP-Ranges belonging to the listed countries. For 
this purpose, what would be the ideal format for directly feeding the produced 
output into ipfw tables?
The format for using tables directly is the same as that used for 
routing tables.
so imagine that you had to generate a routing table that sent packets 
to two different routers depending on their source.


here's a simple rule set that filters web traffic by such a 'routing 
table'
except it's routing to two different rules. It also sorts OUTGOING web 
traffic to the same rules.


ipfw -q /dev/stdin <<-DONE
# we hate this guy
table 5 add 1.1.1.0/32 1000
# but all ow our people to visit everyone else in that subnet
table 5 add 1.1.0.0/24 2000
# we block 1.1.2.0 through 1.1.3.255
table 5 add 1.1.2.0/23 1000
# but we allow 1.1.4.0 through to 1.1.7.255
table 5 add 1.1.4.0/22 2000
# etc
table 5 add 1.1.8.0/21 1000
table 5 add 1.2.0.0/16 1000
table 5 add 0.0.0.0/0 2000 # default
check-state  # If we already decided what to do,  do it
# select out only external traffic, into direction specific rules.
add 400 skipto 500 ip from any to any in recv WAN_if
add 410 skipto 700 ip from any to any out xmit WAN_If
add 320 skipto 1
# Incoming packets
add 500 skipto tablearg tcp from table(5) to any 80,443 setup 
keep-state  # sort tcp setup packets between rules 1000 and 2000

add 600 skipto 1
# outgoing packets
add 700 skipto tablearg tcp from any  to table(5) 80,443 setup 
keep-state  # sort tcp setup packets between rules 100 and 2000

add 800 skipto 1
add 1000 drop ip from any to any
add 2000 allow ip from any to any
# further processing
add 1 .. # further processing for non tcp
DONE

for full configurability you could have a rule for each country, and a 
number for it in the table:

table 5 add 150.101.0.0/16 10610 # Australia
[...]
add 10610 block tcp from any to any 445  # only allow non encrypted 
web to those Aussie scum.

add 10611 allow ip from any to any

then by changing the rules at that location you could ch

Re: ipfw divert filter for IPv4 geo-blocking

[Julian Elischer]

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 way. Once the filter receives a packet from the respective 
divert socket it looks up the country code of the source IP in the 
IP-Ranges database, and if the country code shall be allowed then 
it returns the unaltered packet via said socket, otherwise, the 
filter does no further processing, so the packet is effectively 
gone, lost, dropped, discarded, or whatever would be the correct 
terminology. Is this the really the correct way of denying a 
packet, or is it necessary to inform ipfw somehow about the 
circumstances, so it can run a proper dropping procedure?


I uploaded the filter + accompanying tools to GitHub

   https://github.com/cyclaero/ipdb

Many thnaks for any advices in advance.


I would use a set of IPFW tables with skipto/call tablearg rules 
instead. 


Use the daemon to maintain the IPFW tables. I assume your database 
is a list of of (CIDR, country code) pairs. In that case the daemon 
config should probably map from sets of country codes to table 
values e.g.


table 1 { DE, NL } -> 1,
{ US, UK } -> 10100
table 2 { CN, KO, TR } -> 2

why multiple tables?
if you load the table at once you can assign a country code as the 
tablearg for every run of addresses. all in one table.




Next the daemon would calculate the minimal set of table entries to 
match these policies exactly and patch the kernel table contents if 
the database changes.


This design avoids the userspace<->kernel copies without losing 
flexibility.

___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"



___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

Re: ipfw divert filter for IPv4 geo-blocking

[Julian Elischer]

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 Jan Bramkamp :

I would use a set of IPFW tables with skipto/call tablearg rules instead …

Michael and Jan, many thanks for your suggestions.

As everybody knows, 'Many roads lead to Rome.', and I am already there. I don't 
feel alike going all the way back only for the sake of trying out other routes.

and I personally am responsible for at least parts of several of them ;-)
(parts of ipdivert, netgraph, and various ipfw bits).




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, the divert daemon reads the binary file in one block and stores 
the ranges into a totally balanced binary search tree. Looking-up a country 
code for a given IPv4 address in the BST takes on average 20 nanoseconds on an 
AWS-EC2 micro instance. I don't know the overhead of diverting, though. I guess 
this may be one or two orders of magnitudes higher. Even though, I won't see 
any performance issues.


yes the diversion to user space is not a fast operation. When we wrote 
it, fast was 10Mbits/sec.
The firewall tables use a radix tree (*) and might be slower than what 
you have, but possibly it might be made up for by not having to do the 
divert logic. it's not entorely clear from your description why you 
look up  a country rather than just a pass/block result, but maybe 
different sources can access different countries?.


I did similar once using ipfw tables but couldn't find a reliable 
source of data.




Independent from the actual usage case (geo-blocking), let's talk about divert filtering 
in general. The original question which is still unanswered can be generalized to, 
whether "dropping/denying" a package simply means 'forget about it' or whether 
the divert filter is required to do something more involved, e.g. communicate the 
situation somehow to ipfw.


there is no residual information about the packet in the kernel once 
it has been passed to the  user process.

so just "forgetting to hand it back" is sufficient to drop it.



Best regards

Rolf
___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"




___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

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

[Julian Elischer]

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 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 solve it in a easy way wrongly using existing
  > > > methods.
  > >It is was initial driver for this patch, yes, but, please, read
  > > subject (? is mistype, of course, it is closing ").
  > >
  > >Current set of primitives, dealing with state, is terribly wrong,
  > > IMHO. "keep-state" which trigger (any!) state check alone is awuful,
  > > and complete "keep-state / check-state" pair is ugly hack. It is like
  > > CISC vs RISC, actually.
  > >
  > >New primitives are ORTHOGONAL. Each one solves one and only one
  > > well-defined task, state creation, state checking and command
  > > execution are well-separated. IMHO, "keep-state" in it current form
  > > should be killed with fire. Yes, I understand about backward
  > > compatibility and POLA, so I don't propose to really remove it, but,
  > > IMHO, new set is much, much better.

Lev, is there any chance you and Andrey can work together here?  At the
moment we seem to have two 'competing' models.  Can they be melded at
all?  Or can you live with adding new opcodes on top of Andrey's named
states?  (Feel free to tell me that this is none of my business ..)

yes, please..

  > In writing complicated automatically generated firewalls,
  > I've wanted the following capacities:
  > 1/ one state table for one part of the flow and another  for a different
  > part...  e.g. a different table for "inside" nat to "outside" nat..

Isn't one table with distinct flow-or-whatever names for matching not
sufficient for this purpose?  Wouldn't that also be faster than having
to consult multiple distinct tables?
if you name table entries then you effectively have different tables, 
but yes I was mistaken in how it was being done.

I had assumed a separate table


In the end those are details the user doesn't need to know about .. but
ze does need to comprehend the terms conveying the ideas.

  > also a different table for the inside interface to the outside interface..
  > just because you allow a flow at one interface doesn't mean you want it to 
be
  > allowed through a different one.

Sure, so couldn't you have, say, 'inbound_outside', 'inbound_inside',
'outbound_outside' and 'outbound_inside', 'from_dmz' or whatever to
distinguish multiple flows?

Why doesn't 'flowname' sound right to describe what you call 'flows'?

multiple flows can end up in the same table/name
a flow to me is some set of packets that relate to each other in source,
destination and sequence.  you could almost say that each pair of 
sockets defines a flow.
Others probably have different definitions.. One could even say that 
in the context of
ipfw, any set of packets that can be discriminated by a set of rules 
can be a flow.


  > 2/ The ability to  specifically add a flow's state rule to a table, without
  > EVERY OTHER FLOW hitting a 'check-state' at that point.  If I select s
  > particular flow , then I do not want other flows affected. just that flow
  > should be affected.

Isn't that the case with Andrey's code at the moment, if you specify a
name on that keep-state rule, only that - erm - flow would be checked
and not other flows (including 'default' where added by unnamed rules)?

no. but it is the case with Lev's patch (and Andrey's matching effort)


Can I assume that if this is the first keep-state|limit for one flowname
then an implicit check-state would check that flow only, finding none?
I don't know.  currently the selector part of the rule doesn't 
distinguish who does a check-state.

I'm guessing he finds the label and uses it but I don't know.



Similarly, if I'm grokking this at all right, then only a check-state
(or another keep-state or limit encountered) with that same name will
match existing states having that same name?  Issue 2/ solved or not?


Issue 2 is mostly solved for many cases.


I hope you can see my concern that this be easily described in ipfw(8)
so people without high level of expertise can easily see how it works.

I'll have some more suggestions re description along the way, but after
seeing clear agreement that the proposed model/s cover the usage cases
described (somewhat), and where not, what more needs doing to make it
acceptable as a next step, if not entirely ideal for every case ..

To that end, I'll leave wishes 3/ and 4/ well alone .. as usual, FWI

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

[Julian Elischer]

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 solve it in a easy way wrongly using existing
methods.

   It is was initial driver for this patch, yes, but, please, read
subject (? is mistype, of course, it is closing ").

   Current set of primitives, dealing with state, is terribly wrong,
IMHO. "keep-state" which trigger (any!) state check alone is awuful,
and complete "keep-state / check-state" pair is ugly hack. It is like
CISC vs RISC, actually.

   New primitives are ORTHOGONAL. Each one solves one and only one
well-defined task, state creation, state checking and command
execution are well-separated. IMHO, "keep-state" in it current form
should be killed with fire. Yes, I understand about backward
compatibility and POLA, so I don't propose to really remove it, but,
IMHO, new set is much, much better.

In writing complicated automatically generated firewalls,
I've wanted the following capacities:
1/ one state table for one part of the flow and another  for a 
different part...  e.g. a different table for "inside" nat to 
"outside" nat..
also a different table for the inside interface to the outside 
interface..  just because you allow a flow at one interface doesn't 
mean you want it to be allowed through a different one.
2/ The ability to  specifically add a flow's state rule to a table, 
without EVERY OTHER FLOW hitting a 'check-state' at that point.  If I 
select s particular flow , then I do not want other flows affected. 
just that flow should be affected.
3/ the ability to select a completley different firewall for a 
differnent interface.. this can be simulated at the moment. but it'd 
be nice to be able to specify a entry pont into the table or a 
separate table per interface..   ipfw interface xn0 in enter 5000 or 
something.

or maybe ipfw interface firewall 3
4/ the ability to have variables and set and test them. We ALMOST have 
that with tags .

 i] variables would hav eone of several scopes:
  a) a single transit..  you might set some flag at rule 40 and 
branch on it at rule 4000, but a separate packet would ahv ea 
different instance.
  b) per flow..  assigned at creation of the dynamic  rule and 
avaliable at any time after a packet has been associated with that flow.

  c) global
 ii] branching on values is possible.
there are others I've wanted (and forgotten) but that's the wish-list 
I have at the moment.







As you described in patch to ipfw(8) "Problem is, you need to
create dynamic rule before NAT and check it after NAT actions (or
vice versa) to have consistent addresses and ports."

   It is only very rudimentary example to show the point of new
primitives. All meaningful examples require big and complex rulesets,
really.


In terms of ipfw(4) a state is represented by ipfw_flow_id
structure. To solve your task you just needs two states - one for
not translated flow and second - for translated.

   For what?! Logically it is one flow. NAT is kludge itself, of
course, but, IMHO, logically it doesn't create new flow, or
connection, whatever your name it. It hacks existing one.


Due to limits of implementation this looks impossible to solve. But
proposed patch with deferred action looks too hackish to me.

   IMHO, it untangles current very sad situation.


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

  Named states are great and very useful by themselves, but how this
solve problem, that "keep-state" implies "check-state" rule, for example
?

  I seen a thousand posts, messages and how-tos about stateful IPFW and
all of them suffer from this "keep-state is check-state" problem,
really, when you try to structure your firewall in "ingress / egress"
per-interface sections and not one small ruleset for one interface.

- -- 
// Lev Serebryakov AKA Black Lion

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQJ8BAEBCgBmBQJXWdt4XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF
QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePQ+kP/jTUZQ/W2srUhiRCkTzDsGpy
dbODp6utMjQGwtZKgPRVN4+0KuchgJInA6odB/34WKfgW5THpevLkh5do8QGvm+5
/8DcYZOYwCk45TRkjhctBH6u2t0v3TPvjd1pPkknmhd3qE9Zzkk2fi+0iUWBavMH
LvLJ+afUlmw8l95Om8g4Per3C7TEWmxXews3k+vg1xgrTtPn6m1Vcwspp7gHe2Zo
OIGTzDl0S95SUofQuQX3vD7gPqm6YTnRVhtHrb36saVpP2HCv6e+7vOkyfiTV4nd
Mchu3T6e9zJ2cmWBRIE9d/wB18LRVjWE+pvosTf6EEIkRJnUUnCZF19EJj8BS+9X
7+zbPnVeUSo17YdxSTcDXL0cBuzRIsz50V2Q6bFgl313PB9u97a4FeLdNmqEZfnN
jEgeonc8loN6Fw/Mgjdn2wjmAhZaWU+zCpozzDPcjevkl9NIVVkMys4iZUUCdRkG
yGQtU18X3hHwrbM4uJs7K9JLJj1HHEgpT9mnZ3qxCQ1YKEWZ0plgPvXoFWOiYYIB
Ecz19D/kLBad3gVZ0X9NZwqA2XM23UmfMiKqd0ZcoOPiMY1WY35PQWOocOhiCIW4

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

[Julian Elischer]

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 everything what was requested by reviewers.
  >
  > Hi Lev,
  >
  > 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 solve it in a easy way wrongly using existing methods.
  >
  > As you described in patch to ipfw(8) "Problem is, you need to create
  > dynamic rule before NAT and check it after NAT actions (or vice versa)
  > to have consistent addresses and ports."
  >
  > In terms of ipfw(4) a state is represented by ipfw_flow_id structure.
  > To solve your task you just needs two states - one for not translated
  > flow and second - for translated. Due to limits of implementation this
  > looks impossible to solve. But proposed patch with deferred action looks
  > too hackish to me.
  >
  > 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

If your patch does what Lev wanted to achieve with (I thought too many)
new dynamic rule actions, then I think your simpler solution is better,
not least because it's far easier to understand for non-Julians :)


actually I want only  subset..
what I want is a "set-state"  that is the same as keep-state, but does 
not have
the implicit check-state before it. (if it has a collision with an 
existing rule it overrides it)

I also want he named state tables.   :-)



Looking from a useability and documentation perspective only - I won't
even be looking at this code - I have a few thoughts:

Thus far, keep-state and limit seem to be interchangeable options; limit
rules will need to work the same with respect to named dynamic flows; do
I assume that you've just started with only keep-state for testing?

I think flow names should be specified as an _optional_ parameter, thus:

 check-state [name]

 keep-state [name]

 limit {src-addr | src-port | dst-addr | dst-port} N [name]

where name (maybe flowname, for easier comprehension by man readers?) is
optional, assigned as 'default' whenever omitted - as well as being for
backwards ruleset compatibility, which then only needs mentioning once,
and maybe also put another way in the STATEFUL FIREWALL section.


I think flowname  is a bad name..  it's a state table name.



So a few of the existing example rules with no name could stand, while
others (see below) append names of OUTBOUND and INBOUND or whatever.

As is, you have

740 .It Cm check-state Op Ar name | Cm any | Cm default

which in other contexts would mean you have to supply one of 'name' or
'any' or 'default' when you don't have to provide one, 'default' being
assigned otherwise.  Otherwise I think this is fairly well described.

Will 'ipfw -[e]d list|show' show the flow names? or the indices?

As I pestered Lev about last year, we still need a small example ruleset
section that actually deals with potentially problematic stateful issues
with NAT - which I still don't fully understand - beyond descriptions in
the abstract case; ie an actual working dual- or multi-flow example.

I know these are "just doc" issues of little importance while testing
working code, and I haven't supplied any patches, so are just FWIW ..

cheers, Ian



___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

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

[Julian Elischer]

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,

there are three patches for ipfw, that I want to commit:
https://reviews.freebsd.org/D6420
https://reviews.freebsd.org/D6434
https://reviews.freebsd.org/D6674

But we are in code slush and there aren't any positive review yet. So, I
guess they will be committed only after 11.0 would be branched.


6674 would be good to have.. I;ve given it a +1


The feature I want from Lev's change is the ability to store a state 
entry without the implicit check-state.



___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

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

[Julian Elischer]

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 forget who he is in email or I'd send him one asking for some action.


___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

Re: [RFC] ipfw named states support

[Julian Elischer]

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 check-state and keep-state rules:

  check-state { token | default | any }
  keep-state { token | default }



1. Is this feature useful?

Yes.

2. How to commit it? Due to changed syntax it can break existing
rulesets. Probably, we can add some mandatory prefix to state name, 
e.g.

':'.
Maybe create new opcode, e.g. "save-state", and deprecate 
"keep-state" with "save-state default".
I'm sorry I didn't understand what Lev Serebryakov suggests, and I 
could duplicate his suggestion.
I have already hoped for  a different version of keep-state, that 
saves the state without actually acting upon it.


Maybe there is a sense to add "search-state" option and use it 
instead of "check-state" action. E.g. "allow dst-port 80 
search-state NAME".

___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"




___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

Re: [RFC] ipfw named states support

[Julian Elischer]

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 that can be used for multiple interfaces.
(I guess we need variables first)



This expands flexibility and functionality.
Imagine the situation:

[ LAN1 ] <---> [ FW ] <---> [ LAN2 ]

   add skipto 1 ip from any to any via lan1
   add skipto 2 ip from any to any via lan2
   add deny ip from any to any
   add 1 count ip from any to any
   ...
   add allow ip from  to any keep-state in
   add deny ip from any to any
   add 2 count ip from any to any
   ...
   add allow ip from  to any keep-state in
   add deny ip from any to any

The problem is that a state created by first keep-state rule will act on
second keep-state rule and allow traffic to go into (out from router's
point of view) lan2 without any rules actually allowing that.

With named states we can create separate states for each interface and
they will not match when we don't want this.

what does the ipfw -d list   output look like?

What I want to discuss
--

1. Is this feature useful?
2. How to commit it? Due to changed syntax it can break existing
rulesets. Probably, we can add some mandatory prefix to state name, e.g.
':'.



___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

Re: IPW problem

[Julian Elischer]

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
Cable connection 200 Mbit/20 Mbit

I have to use NIC1 for all services I'm running, but when the home server
wants to download something e.g. the ports, then it has to use NIC2

How can this be done using IPFW???
IPFW is compiled in the kernel. I'm using FreeBSD 10.3-STABLE

Thanks for the help


where is the NAT hapenning? at each of the modems?

If so, configure 2 FIBs
then assign regular behaviour fib 0  but make fib 1 have the cable 
modem as default
all 'fetch' operations should then be performed with fib 1. e.g. 
setfib 1 fetch https:example.com/test.txt



Jack


___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"



___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

Re: Network goes down when installing ipfw

[Julian Elischer]

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 does not support.

 I have also digitally signed by Microsoft kernel mode 
signing

process for authenticate the publisher.


Process of installing: Local Area Connection-> properties -> 
Install ->

service -> Add ->OK (I can also see there message by system  "Driver
digitally signed")


this is amusing..  Ipfw on windows?  I never knew of this..

can you send us all the links to this project?

never mind:

google to the rescue:

 http://wipfw.sourceforge.net/


Could anyone please help me for this issue. Thanks in advance.


With Regards,
Kulamani Sethi,
India
___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to 
"freebsd-ipfw-unsubscr...@freebsd.org"




___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"



___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

Re: Network goes down when installing ipfw

[Julian Elischer]

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 digitally signed by Microsoft kernel mode signing
process for authenticate the publisher.


Process of installing: Local Area Connection-> properties -> Install ->
service -> Add ->OK (I can also see there message by system  "Driver
digitally signed")


this is amusing..  Ipfw on windows?  I never knew of this..

can you send us all the links to this project?

Could anyone please help me for this issue. Thanks in advance.


With Regards,
Kulamani Sethi,
India
___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"



___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

Re: ipwf dummynet vs. kernel NAT and firewall rules

[Julian Elischer]

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:
  > 
  >  ?Do you have the sysctl net.inet.ip.fw.one_pass set to 0 or 1?
  > >>>
  > >>> Aha, I've got it set to 1.

I observe that in 99 cases out of 100, the default of 1 is undesired,
but it's too late to do anything but advise people - thanks Freddie!


Is there any reason why we shouldn't just change the default for
11-RELEASE?


yeah people will kill you.
firewalls don't get rewritten by mergemaster.





___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

Re: ipwf dummynet vs. kernel NAT and firewall rules

[Julian Elischer]

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 dummynet pipe/sched/queue
instances using example 3.3a from this document
 with the
appropriate bandwidths, but otherwise default tunings to shape both
inbound and outbound traffic.  My inside network is a /24 and I have an
external /29 (ext/29) network that I don't want to rate limit.  My
outside network interface is re0.  I'm using the /etc/rc.firewall
"simple" firewall configuration.

The problem that I'm having crops up when I actually try to add the
firewall rules to select the traffic that I want to rate limit.  The
first rule in the list is:
100 allow ip from any to any via lo0
The second rule is numbered 200 and is first anti-spoofing rule.  If
I add *either* of these two rules, then I'm no longer able to
communicate between hosts on my internal network and the rest of the
world:

   ipfw 110 add queue 1 ip from not ext/29 to any in recv re0
   ipfw 120 add queue 2 ip from any to not ext/29 out xmit re0

It seems like the inbound rule should be early in the rule list so that
any inbound traffic that gets dropped by the firewall rules gets counted
even if it is dropped by later rules.  It also seems like the outbound
rule needs to be before any allow rules since an allow rule would skip
the remaining rules and would not count that traffic.  Unfortunately the
ipfw documentation doesn't really describe the interaction between
dummynet, NAT, and other firewall rules.

Unfortunately this is a live system, so it is difficult to do controlled
experiments and look at the ipfw counters to see where things might be
going into the weeds ...


ok so you need to do what I always tell people.. split your rules into 
separate incoming and outgoing rule sets.

so your first rule should be:
  skipto 1 all from any to any in.


and have separate sets of rules for incoming and outgoing packets.

Then you should always set one_pass to 0  and expect your packets to 
come back to the firewall at the next number.





___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"



___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

Re: ipwf dummynet vs. kernel NAT and firewall rules

[Julian Elischer]

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
packet never gets to the NAT rules.  Or, if a NAT rule matches, the trip
through the rules ends, and it never get to the dummynet rules.  Depending
on which you have first.

Dummynet is first.


You'll need to set net.inet.ip.fw.one_pass?=0 in order to re-inject the
packet into the rules after it matches a dummynet or NAT rule.  Or, do the
NAT and dummynet rules on different interfaces to match different traffic.

How do I prevent the re-injected packets from being sent back into
dummynet?  My NAT rule looks like it could have the same problem, but
that looks fixable.

I just read the fine man page and is says that after re-injection the
packet starts with the next rule ... cool!


actually it doesn't... it starts at the next rule NUMBER  which may be a 
different thing.
 


Ignoring dummynet for a moment since I haven't added those rules back
... DNS lookups break when I set net.inet.ip.fw.one_pass=0.  This
machine is running BIND as a DNS forwarder and I have this rule to
allow DNS lookups in and out:
   pass udp from me to any 53 out via re0 keep-state

If BIND has the results of a lookup cached, then I get the expected
query results from an internal host when I set
net.inet.ip.fw.one_pass=0, but if the results are not cached I get
";; connection timed out; no servers could be reached" when I do a
lookup on an internal host, and running the query on the firewall
machine also does not work.  If BIND has the query cached, I am able
to download from servers on the internet to an internal host, so that
indicates that NAT is functioning, but it shouldn't be involved in DNS
lookups.


___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"



___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

Re: layer2 ipfw fwd

[Julian Elischer]

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 someone to build a
competing open source FreeBSD-based web filter appliance with this same
feature set...

nah...there is SO MUCH MORE to what the ironport does.






___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

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

[Julian Elischer]

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 how i set
  >
  > C:>ipfw add 1002 deny log ip  from www.google.com to any
  >
  > As i know most of the websites uses dynamic IP, it simple changes there IP
  > periodically. This rule i set for google is worked for few moment, then it
  > allow the packets to my terminal.

the only way to do this is to make a daemon similar to what I wrote 
for cisco many years ago.
it acts as a DNS 'man-in-the-middle' and compares all DNS responses 
against black/white lists.

WHen it gets a hit it:
1/ returns a suitably altered answer.
2/ adds the address found to a black or white table in ipfw.

Since Secure DNS is getting more popular, it would probably make more 
sense these days to make unbound or bind

feed their work through some filter module to do the same thing.

___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

Re: Kernel NAT issues

[Julian Elischer]

ee.fff.gg.hhh TCP 64 42957→5432 [SYN] Seq=0 
Win=65535 Len=0 MSS=16344 WS=64 SACK_PERM=1 TSval=142885525 TSecr=0
   2   3.01390510.0.0.25 -> eee.fff.gg.hhh TCP 64 [TCP Retransmission] 
42957→5432 [SYN] Seq=0 Win=65535 Len=0 MSS=16344 WS=64 SACK_PERM=1 TSval=142888539 
TSecr=0
   3   6.24165810.0.0.25 -> eee.fff.gg.hhh TCP 64 [TCP Retransmission] 
42957→5432 [SYN] Seq=0 Win=65535 Len=0 MSS=16344 WS=64 SACK_PERM=1 TSval=142891767 
TSecr=0
   4   9.45151610.0.0.25 -> eee.fff.gg.hhh TCP 64 [TCP Retransmission] 
42957→5432 [SYN] Seq=0 Win=65535 Len=0 MSS=16344 WS=64 SACK_PERM=1 TSval=142894976 
TSecr=0
   5  12.65465610.0.0.25 -> eee.fff.gg.hhh TCP 64 [TCP Retransmission] 
42957→5432 [SYN] Seq=0 Win=65535 Len=0 MSS=16344 WS=64 SACK_PERM=1 TSval=142898180 
TSecr=0
   6  15.86390010.0.0.25 -> eee.fff.gg.hhh TCP 64 [TCP Retransmission] 
42957→5432 [SYN] Seq=0 Win=65535 Len=0 MSS=16344 WS=64 SACK_PERM=1 TSval=142901389 
TSecr=0
   7  22.07665510.0.0.25 -> eee.fff.gg.hhh TCP 64 [TCP Retransmission] 
42957→5432 [SYN] Seq=0 Win=65535 Len=0 MSS=16344 WS=64 SACK_PERM=1 TSval=142907602 
TSecr=0



If so, what sort of routing is setup on both host and jails?

Routing is what would be added by default (whatever the host system adds when 
adding an IP), there is no custom routing. I have wondered if I need to modify 
the routing table to get this to work.

Below is the output of netstat -rn

www.xxx.yy <http://www.xxx.yy/>.zzz is the gateway address
eee.fff.gg.hhh is the database jail public IP
aaa.bbb.cc.ddd is the public IP for NAT
lll.mmm.nn.ooo is the Hosts public IP


Routing tables

Internet:
DestinationGatewayFlags  Netif Expire
defaultwww.xxx.yy <http://www.xxx.yy/>.zzz UGSbce0
10.0.0.1   link#6 UH  lo1
10.0.0.2   link#6 UH  lo1
10.0.0.3   link#6 UH  lo1
10.0.0.4   link#6 UH  lo1
10.0.0.5   link#6 UH  lo1
10.0.0.6   link#6 UH  lo1
10.0.0.7   link#6 UH  lo1
10.0.0.8   link#6 UH  lo1
10.0.0.9   link#6 UH  lo1
10.0.0.10  link#6 UH  lo1
10.0.0.11  link#6 UH  lo1
10.0.0.12  link#6 UH  lo1
10.0.0.13  link#6 UH  lo1
10.0.0.14  link#6 UH  lo1
10.0.0.15  link#6 UH  lo1
10.0.0.16  link#6 UH  lo1
10.0.0.17  link#6 UH  lo1
10.0.0.18  link#6 UH  lo1
10.0.0.19  link#6 UH  lo1
10.0.0.20  link#6 UH  lo1
10.0.0.21  link#6 UH  lo1
10.0.0.22  link#6 UH  lo1
10.0.0.23  link#6 UH  lo1
10.0.0.24  link#6 UH  lo1
10.0.0.25  link#6 UH  lo1
10.0.0.26  link#6 UH  lo1
www.xxx.yy.zzz/25 <http://www.xxx.yy.zzz/25>  link#1 U  bce0
eee.fff.gg.hhh link#1 UHS lo0
eee.fff.gg.hhh/32  link#1 U  bce0
aaa.bbb.cc <http://aaa.bbb.cc/>.ddd link#1 UHS lo0
aaa.bbb.cc.ddd/32  link#1 U  bce0
lll.mmm.nn.ooo link#1 UHS lo0
127.0.0.1  link#5 UH  lo0

Internet6:
Destination   Gateway   Flags  
Netif Expire
::/96 ::1   UGRSlo0
::1   link#5UH  lo0
:::0.0.0.0/96 ::1   UGRSlo0
fe80::/10 ::1   UGRSlo0
fe80::%lo0/64 link#5U   lo0
fe80::1%lo0   link#5UHS lo0
ff01::%lo0/32 ::1   U   lo0
ff02::/16 ::1   UGRSlo0
ff02::%lo0/32 ::1   U   lo0


Anything like ?
http://kb.juniper.net/InfoCenter/index?page=content=KB24639=search 
<http://kb.juniper.net/InfoCenter/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 some reason hairpin (loopback nat or nat reflection) does not seem to
be working, which is why I chose IPFW in the first 

Re: Kernel NAT issues

[Julian Elischer]

 public IP


Routing tables

Internet:
Destination GatewayFlags  Netif Expire
default www.xxx.yy <http://www.xxx.yy/>.zzz UGSbce0
10.0.0.1 link#6 UH  lo1
10.0.0.2 link#6 UH  lo1
10.0.0.3 link#6 UH  lo1
10.0.0.4 link#6 UH  lo1
10.0.0.5 link#6 UH  lo1
10.0.0.6 link#6 UH  lo1
10.0.0.7 link#6 UH  lo1
10.0.0.8 link#6 UH  lo1
10.0.0.9 link#6 UH  lo1
10.0.0.10 link#6 UH  lo1
10.0.0.11 link#6 UH  lo1
10.0.0.12 link#6 UH  lo1
10.0.0.13 link#6 UH  lo1
10.0.0.14 link#6 UH  lo1
10.0.0.15 link#6 UH  lo1
10.0.0.16 link#6 UH  lo1
10.0.0.17 link#6 UH  lo1
10.0.0.18 link#6 UH  lo1
10.0.0.19 link#6 UH  lo1
10.0.0.20 link#6 UH  lo1
10.0.0.21 link#6 UH  lo1
10.0.0.22 link#6 UH  lo1
10.0.0.23 link#6 UH  lo1
10.0.0.24 link#6 UH  lo1
10.0.0.25 link#6 UH  lo1
10.0.0.26 link#6 UH  lo1
www.xxx.yy.zzz/25 <http://www.xxx.yy.zzz/25> link#1 U  
bce0

eee.fff.gg.hhh link#1 UHS lo0
eee.fff.gg.hhh/32 link#1 U  bce0
aaa.bbb.cc <http://aaa.bbb.cc/>.ddd link#1   UHS lo0
aaa.bbb.cc.ddd/32 link#1 U  bce0
lll.mmm.nn.ooo link#1 UHS lo0
127.0.0.1 link#5 UH  lo0

Internet6:
Destination   Gateway   Flags 
Netif Expire

::/96   ::1   UGRS   lo0
::1   link#5UH   lo0
:::0.0.0.0/96   ::1   UGRS 
  lo0

fe80::/10   ::1   UGRS   lo0
fe80::%lo0/64   link#5U   lo0
fe80::1%lo0   link#5UHS   lo0
ff01::%lo0/32   ::1   U   lo0
ff02::/16   ::1   UGRS   lo0
ff02::%lo0/32   ::1   U   lo0


Anything like ?
http://kb.juniper.net/InfoCenter/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 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.


Anything like ?
http://kb.juniper.net/InfoCenter/index?page=content=KB24639=search

Was this so one jail can only access service/s provided by other 
jail/s,
both/all with internal NAT'd addresses, by using only the public 
address
and port of the 'router', which IIRC this is a single system with 
jails?


If so, what sort of routing is setup on both host and jails?

(blindfolded, no idea where I've pinned the donkey's tail :)

cheers, Ian






___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

Re: Kernel NAT issues

[Julian Elischer]

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.



___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

Re: ipfw delete 100-300

[Julian Elischer]

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
  [...]
  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
  [...]
  65535   8251 16045693110842147290 deny ip from any to any
 
 
  -current as of the 5th of august
  FreeBSD vps1.elischer.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1 
r286304: Wed
  Aug  5 14:31:10 PDT 2015
  r...@vps1.elischer.org:/usr/obj/usr/src-current/sys/VPS1  i386
 
  note i386, not amd64.
   
Assuming all digits were shown, on a wild hunch:
   
t23% echo 'scale=20; 2^64 - 16045693110842147038' | bc
2401050962867404578
t23% echo 'scale=20; 2^63 - 16045693110842147038' | bc
-6822321073987371230
   
  
bc
   obase=16
   16045693110842147038
   DEADC0DEDEADC0DE
  
   so... somehow pointing in a bad place.

Ah, quite so .. and rule 65535 looks like a slightly worse place.

t23% echo 'obase=16; 16045693110842147290' | bc
DEADC0DEDEADC1DA

that's deadcode when it's had some packets added to it :-)

I think our friend Mr Chernikov may have tripped up over something..




thanks, Ian



___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

Re: ipfw delete 100-300

[Julian Elischer]

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
  [...]
  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
  [...]
  65535   8251 16045693110842147290 deny ip from any to any
 
 
  -current as of the 5th of august
  FreeBSD vps1.elischer.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1 
r286304: Wed
  Aug  5 14:31:10 PDT 2015
  r...@vps1.elischer.org:/usr/obj/usr/src-current/sys/VPS1  i386
 
  note i386, not amd64.
   
Assuming all digits were shown, on a wild hunch:
   
t23% echo 'scale=20; 2^64 - 16045693110842147038' | bc
2401050962867404578
t23% echo 'scale=20; 2^63 - 16045693110842147038' | bc
-6822321073987371230
   
  
bc
   obase=16
   16045693110842147038
   DEADC0DEDEADC0DE
  
   so... somehow pointing in a bad place.

Ah, quite so .. and rule 65535 looks like a slightly worse place.

t23% echo 'obase=16; 16045693110842147290' | bc
DEADC0DEDEADC1DA

thanks, Ian


this is a few days old.  I'll check the newest one later tonight.

___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

Re: ipfw delete 100-300

[Julian Elischer]

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
[...]
65535   8251 16045693110842147290 deny ip from any to any


-current as of the 5th of august
FreeBSD vps1.elischer.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1 
r286304: Wed Aug  5 14:31:10 PDT 2015 
r...@vps1.elischer.org:/usr/obj/usr/src-current/sys/VPS1  i386


note i386, not amd64.


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

Re: ipfw delete 100-300

[Julian Elischer]

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 it was a bug),
   Now I see that its just 'not supported'

I implemented the kernel range deletion, but converted userland part as-is.
Should work on HEAD now (r286232).


great!
Pitty I'm stuck working on 8.0 :-) maybe I can back-port it.




  
   It may be my imagination but (distant) past?

I was surprised too; ISTR having used that before too, but I may
misremember remembering ..

I also had a feeling that this syntax should work (maybe because it silently accepted 
ranged queries) but I couldn't find any presence of real ranged deletion 
support in SVN.

On 9.3 with rules 100-1000 in 100's, 'ipfw delete 600-800' deletes only
600 .. without complaint, returning 0 if 600 existed. NG for scripts.

cheers, Ian
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org




___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

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

[Julian Elischer]

On 7/29/15 10:23 PM, bycn82 wrote:

/Hi,/
/But I dont understand why you said C-D is already in the dynamic 
table?  which line create the dynamic rule for it?/


/it happened on a previous packet at some other rule,  for example
30 allow ip from any to D 80 keep-state


/

/
/
/Regards,/
/bycn82/

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/
/10{action} from A to B keep-state/
/11{action} from C to D/
/
/
/
/
/If I remove the skipto rules they will become/
//
/10 {action} from A to B keep-state/
/11 {action} from C to D /
/
/
/Correct me if I was wrong,  but in my opinion, the rule 5 and
10 are almost the same, so I dont see the benefit by
introducing the skipto rulees. //IMHO, the check-state is
to speed-up some selected packets, it will slow-down all other
unexpected 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 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 future and I remember about
these examples.


there are some simple examples of things this patch addresses..
For example in the current code, the following (extemely
simplified) set of
rules will not do what you would think when you are working
with a tcp
session from A to B and another from C to D *which has
previously been**
**accepted with a keep-state at some other point in the
ruleset*


10 {any action} from A to B keep-state
20 {any action} tcp from C to D

because despite the fact that you are only triggering on a
'setup' packet for A to B, any rule
that includes keep-state does a check-state implicitly.
so the packet  from C to D never gets past rule 10.
the only way you can do this is to prefix rule 10 by
something like

5 skipto 10 from A to B
6 skipto  11 from any to any

to make sure packets that are not A to B  do not hit the
hidden 'check-state' .

this is  a very simple example and yes there are ways to
get around it,
but it complicates the ruleset and increases errors

that reminds me I'd also like to be able to put a not at the
front of the rule matching to negate the whole test but it
doesn't seem to like that.




___
freebsd-ipfw@freebsd.org mailto:freebsd-ipfw@freebsd.org
mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to
freebsd-ipfw-unsubscr...@freebsd.org
mailto:freebsd-ipfw-unsubscr...@freebsd.org







___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

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

[Julian Elischer]

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 future and I remember about these examples.




there are some simple examples of things this patch addresses..
For example in the current code, the following (extemely simplified) 
set of

rules will not do what you would think when you are working with a tcp
session from A to B and another from C to D *which has previously been**
**accepted with a keep-state at some other point in the ruleset*


10 {any action} from A to B keep-state
20 {any action} tcp from C to D

because despite the fact that you are only triggering on a 'setup' 
packet for A to B, any rule

that includes keep-state does a check-state implicitly.
so the packet  from C to D never gets past rule 10.
the only way you can do this is to prefix rule 10 by something like

5 skipto 10 from A to B
6 skipto  11 from any to any

to make sure packets that are not A to B  do not hit the hidden 
'check-state' .


this is  a very simple example and yes there are ways to get around it,
but it complicates the ruleset and increases errors

that reminds me I'd also like to be able to put a not at the
front of the rule matching to negate the whole test but it doesn't 
seem to like that.





___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

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

[Julian Elischer]

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/
/10{action} from A to B keep-state/
/11{action} from C to D/
/
/
/
/
/If I remove the skipto rules they will become/
//
/10 {action} from A to B keep-state/
/11 {action} from C to D /
/
/
/Correct me if I was wrong,  but in my opinion, the rule 5 and 10 
are almost the same, so I dont see the benefit by introducing the 
skipto rulees. //IMHO, the check-state is to speed-up some 
selected packets, it will slow-down all other unexpected 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 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 future and I remember about these
examples.


there are some simple examples of things this patch addresses..
For example in the current code, the following (extemely
simplified) set of
rules will not do what you would think when you are working with
a tcp
session from A to B and another from C to D *which has
previously been**
**accepted with a keep-state at some other point in the ruleset*


10 {any action} from A to B keep-state
20 {any action} tcp from C to D

because despite the fact that you are only triggering on a
'setup' packet for A to B, any rule
that includes keep-state does a check-state implicitly.
so the packet  from C to D never gets past rule 10.
the only way you can do this is to prefix rule 10 by something like

5 skipto 10 from A to B
6 skipto  11 from any to any

to make sure packets that are not A to B  do not hit the hidden
'check-state' .

this is  a very simple example and yes there are ways to get
around it,
but it complicates the ruleset and increases errors

that reminds me I'd also like to be able to put a not at the
front of the rule matching to negate the whole test but it
doesn't seem to like that.




___
freebsd-ipfw@freebsd.org mailto:freebsd-ipfw@freebsd.org
mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to
freebsd-ipfw-unsubscr...@freebsd.org
mailto:freebsd-ipfw-unsubscr...@freebsd.org




___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

Re: ipfw on just inbound and not outbound

[Julian Elischer]

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.

Is there a way to tell ipfw to not look at outbound traffic at all?

no


OR, the rule I mentioned is the best that can be done here?

yes

this touches on something I've been thinking of for a while.. per 
interface/direction rule sets.

but that doesn't exist yet.

you could write a kernel module that would disconnect the outgoing 
packet filter hooks

but hack comes to mind as a description there.

actually  you could use the ipfw netgraph hook and only hook it up 
for incoming packets,
but it would probably be not much more efficient than just having the 
rule, and more complicated to set up.




cheers,
Hiren

ps: Please keep me cc'd as I am not subscribed.


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

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

[Julian Elischer]

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 router with 2 uplink ISPs.


can you put it in the code review system so I can annotate and comment 
on it?




___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

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

[Julian Elischer]

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?


/


let me have a go at this:

when you write complicated rule sets with state, you start having 
problems where the state is too broad, or contains things you don't 
want in the place where you are using it.. sure you want 
packet/session A to set the state, but you don't want state for 
session B to trigger there at the same time.


this allows you to set a state/action for all future packets in the 
session without triggering sessions you didn't mean to, or actually 
doing that action yourself right now.

this give you a lot more flexibility in the sets you can create.

An example here is combining NAT with session state. You can only have 
the rule active on one side of the NAT.
If you want ot have state on the 'inside' of the NAT then you want 
outgoing processing to continue on, so that the NAT is then used.
However if you try do the check-state on input After the NAT (you need 
to do NAT on the same 'side' of the NAT for both incoming and 
outgoing) then you end up having to do various tricks to avoid being 
diverted into output processing.
what you want to do is be able to set a rule that will handle the 
incoming packets in a way you want but doesn't do the same thing for 
the outgoing packets.
Come to think of it another answer might be the ability to specify 
different actions for a session for incoming and outgoing, but that 
would be quite hard to do.  at least this way you can specify a rule 
for input without having to do the same thing on output.
there are other drawbackss . like if you have another check-state in 
the output path, it will still trigger on the packet and do what you 
didn't expect. but I think this is an improvement.


Having said that. I'd REALLY like to have multiple dynamic sets and be 
able to specify which set I'm looking in.
then you could have differnt dynamic rules for NAT'd and unNATed 
packets, and differnet rules for the same packets as they traverse 
different interfaces.


Lev, I think this is an improvement, but I wonder if we can make it 
even better.


Julian


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

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

[Julian Elischer]

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 that was but it's just
wrong. (if the state exists, maybe just replace it..)

   Update, not replace :)
   See my Version-3 patch for record-state :)
I meant a function that acts like 'keep-state' except it does not do a 
'check-state'.

Im suggesting adding yet-another command. a 'fixed' keep-state.

I sort of know why they did it.. so that if the state for that session 
already exists,
the original state rule is used and not the new rule. but ..it fires 
on other packets

as well as the one you are working with.




- -- 
// Lev Serebryakov AKA Black Lion

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQJ8BAEBCgBmBQJU0eTUXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF
QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePoS0P/iCMeTo+fFA4iGwe/8FnlF+y
899fomt4tzOBppxg1r5/xx11OMB9DJ6VG1z8+61gzIg1jgxvAIBTBGz5oxIgyfv5
mtbEbfhsxsABYTASjwIQymxR1zvLCbyd7fWgDRhM8YJYEy/akWNzOwtbokrkK1Ww
3j2IODup3onYr5LhwoQZGPdtmIyH10rnEcs49IWUs1ZweWlJx7XRQOGBAepTQRx9
bh/D0owV1j9BBzyqd5n54aXiQpMKMIdOihmNOOUYhl0B3GksacWguV7Keabbv0Dh
Nnk3g/GrBYJPdmF0JqkocjrGxSuWAwBXfdXg3SoG8l1dPqaDg8UNVXq7VthS7FKO
8jyoRXaptbcrTjgG0SHdfnSzbhpLj78/PdGi1VvJwrvjnK2MNb6dZ2PE3E88ScgM
f7OIOef9GyLwgAPqn6TJeiC7Oddvq+vL1vEigqLMJscJ4ErwqX8RVidbkYdNmKCf
HYSd9mSJgkAMUH7q2U5PCRY9Ay6BOkuGHEqvMHGFClqBWb81RTyT8ZR+BL+JeqRr
QNilMWvUXJSGEcvMYijKiv2EVDB6by3sY2SK9KLa93H0jY1nR3XPpilpyLcHLzN9
5aVknqR2/TzFDS1BiSEg/wYipyqjgIyHTqqxj0Vd0pnZMSw3AqdrOSLz8mHJzXKp
3J8Y7Lw7fuM1N8Doq2Md
=/M0i
-END PGP SIGNATURE-
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org



___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

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

[Julian Elischer]

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 after state creation. It allows to write stateful + nat
firewall as easy as:

nat 1 config if outIface

1000 skipto 2000 in
  skipto 3000 out
  deny all from any to any // Safeguard
2000 skipto 4000 recv inIface
  skipto 6000 recv outIface
  deny all from any to any // Safeguard
3000 skipto 5000 xmit inIface
  skipto 7000 xmit outIface
  deny all from any to any // Safeguard
4000 // For sake of simplicity!
  // Real firewall will have some checks about local network here
  allow all from any to any
  deny all from any to any // Safeguard
5000 // For sake of simplicity!
  // Real firewall will have some checks about local network here
  allow all from any to any
  deny all from any to any // Safeguard
6000 deny all not dst-ip $EXT_IP
  nat 1 all from any to any
  // All enabled with keep-state-only at block 7000 before NAT
  check-state all from any to any
  // Here could be accept rules for our servers or servers in DMZ
  // Disable everything else
  deny all from any to any
7000 // Here goes rules which could DISABLE outbound external traffic
  // Create state for check-state at block 6000 and fallthrough
  allow keep-state-only
  allow src-ip $EXT_IP  // Save NAT some work
  nat 1 all from any to any
  allow all from any to any
  deny all from any to any // Safeguard

  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!

can we get rid of it?  (implied).. or just add everything
also I am not sure about keep-state-only..
how about 'set-state'?  or record-state as I started with..




- -- 
// Lev Serebryakov

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQJ8BAEBCgBmBQJU0POaXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF
QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePR+gP/1Oxi+h7pi0UlnqfrKyfHJRS
FUbrMNeR9NATnTwxIK1UxNT1kF3m7wiwnFlgwW7rwLtTviFB1wK/pfd38l2h4t/w
qUbtyK4PFMCq8I6wAJIB0qUl3C/mN1rwc+LSJJyFM07R52snoQs6FvkIYkCz0fOy
Cak1f/P+scc21IRhFvYJXMMDO/1Y1nkxZk/HdHbn1GELpTXuHugvL1T9hHl98sqO
HKlHnvtqAVlyZn9Sv3uC9nsyjFA2sdOCtb67UGnPDV3CIs4Jwj5CSst5jbz13qFG
aXF8ZSm0coPJMUjH1PSogZM9Xiq23yZ47V0mesBxQsHL24548jM/wKcsR3buDjP7
NJ2rqo2OBCzTu6VCK2oIY5j9A6vq1mu8+/eBs5jF4C2k0xHiw53Okou7zOCA0gJ+
z+VGZvD3la/+tFjacty7Ra7LLNA8kNCnRa0QML7LOJ1/99a4l3Z/uGFxy5zYnk7d
p27Y85CAhTJQjkYZSGAiFD5SE4XxRqtSJ9OL89w7vLxoHqW0rqwi+DVrr9uvXQZS
8Z5G5iQARG4ygXuKsl6MlwChCXa3ucbOs41lorrug94cuVCwGg859zBZY3dpQsKz
XIhtVQS21wPLxXywzIc678ar4uKVWNiaRWg+k57O7375gAszvqujRuTEcfHRf/T+
gHJJZt8Tc+en4bw8XItY
=wOAJ
-END PGP SIGNATURE-


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

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

[Julian Elischer]

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 NAT after that. I know
two:

(a) skipto-nat-allow pattern from many HOWOTOs

Lev, can you provide references for these HOWTOs you refer to?

I have a suspicion that some of them should be taken out and shot.

  google for FreeBSD ipfw nat stateful :) There are lot of them. Not
real HOWTOs, but blog posts  alike.

  BTW, without new mechanism it is really hard to do such firewall, as
we need action (nat) after allow keep-state. It could be done with
this ugly skip-to or with allow keep-state in INCOMING section of
firewall, what is not much better, as I prefer to decide let packet
out or not in OUTCOMING part of firewall and with allow keep-state
in incoming path it flood state table with unused states.

  Another problem, that keep-state acts as check-state too, so you
could not have ANOTHER keep-state before NAT in outgoing part or you
miss nat completely (sate is created in outgoing path, and then
checked before nat in outgoing path with keep-state, gr, ugly!).


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 that was but it's just wrong. 
(if the state exists, maybe just replace it..)






- -- 
// Lev Serebryakov AKA Black Lion

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQJ8BAEBCgBmBQJU0KGqXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF
QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePYvYQALeGCF9EuZKP3jLDaRwad+TO
IhYq5I3xPPqU3eNEdQ6OqdFonVQ4mDB+UipZzspC/U5drf1qo2LkOF8oBNDlVDW4
2I+bgYStptIkpSoBOe5AGRYwO3jfec77GvXhR8cMeQZK2Z9NIazn5ZtFkdQyiiDU
+b7pxBQ0SbbMUT3hubl4H+v93dMGfjnzrFg1aSY4/uYnmilb8plWN1o4BshZVMSz
z1lrFSaorj4RNYxnpM6f6YtDDYx4TahA7+OILl/BvzmNoztWb5hKNX+1TGLZPcch
QE19iix+8O75yuVEMim6FxZ7u6sRk+4PpL/WzCLC2PpPxP/AyiFRh4zw7Q34HDNm
xPe4Nfzt5vDj0/2HYMY0q0UeSfVY/U0iB3TWmV/3HFObaLeibCgHqOFGmtCpHw5/
EXJX36mpffO1wI6ImPAvQ9C/wE6/JdoL8R3EPrsN3hdNmoVNIrnDuaeAwiQM6Ljm
4CHzsqlYYzyjzgyMmmJahaZ3Lrr0IjnVixC3/z46SfpPipaua8Pr+oZozC4WFmnn
4IhsXH+XK7fTbKQaZML6o9j6Bm0hs9g6mt+VSWCYWGCHh/V3DzTuH2BECUeC8lsD
9pwHv4x4vPbh7d/kBwAl75mOe3etb8nD/+i+x0oqbPn0T73DgdGgYPnIKqElOi4Y
Ws6uw/Euno3YnSSds5Eb
=FJZe
-END PGP SIGNATURE-
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org



___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

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

[Julian Elischer]

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 as keep-state BUT
cancel match of rule after state creation. It allows to write
stateful + nat firewall as easy as:

  To work as expected, keep-state-only should not imply check-state
in opposite to keep-state.


agreed.. I hate the implied check-state..
man page must be very explicit about this..


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

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

[Julian Elischer]

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!

can we get rid of it?  (implied).. or just add everything
also I am not sure about keep-state-only..
how about 'set-state'?  or record-state as I started with..

or record-session.. (state always annoyed me)






___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

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

[Julian Elischer]

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 connections
passed through NAT.


yes, because NAT is a stateful filter so it's a duplication
- -- 
// Lev Serebryakov AKA Black Lion

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)



___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

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

[Julian Elischer]

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 allow and deny.

  So, stateful firewall with NAT could be rewritten like this:

add 1000 skipto 2000 all from any to any out xmit outIface
add 1010 skipto 3000 all from any to any in  recv outIface

add 2000 state-allow from any to any // keep-state is implied
add 2010 nat NR from any to any // No out here!
add 2020 allow all from any to any

add 3000 nat NR from any to any
add 3010 check-state // Use dynamic rule based on 2000 as allow here

  What do you think?


I understand what you are trying to do..
but part of the usefulness of the state runes is that they
can be any action, not just allow and deny.
I might try the following action:

record:  (or record-only)
it allows the rule to be stored, but the action is not performed.
on check-state, the rule is performed..

so skipto 2000 ip from me to fred 80 record-only out xmit bge0
would do nothing but record the session
and on input the session packet would skipto 2000

you could do deny or accept  as well so it's a superset of what you 
suggest.

I'm not sure where in the rule record-only shoudl be put..
maybe

ipfw add 1000 log record-only skipto 2000 tcp from me to fred 80,443 
out xmit bge0


might be more syntactically correct?

What I would find more useful, is separate state rules for each interface.
so you could not have the danger of a packet on interface A adding a 
rule that eventually does something unexpected on a packet on interface B.



looking at my own rules I don't seem to have a problem..

Just for kicks,
here is the base ipfw script.. just sets up the framework

---
#!/bin/sh

fwcmd=/sbin/ipfw

# Suck in the configuration variables.
if [ -z ${source_rc_confs_defined} ]; then
if [ -r /etc/defaults/rc.conf ]; then
. /etc/defaults/rc.conf
source_rc_confs
elif [ -r /etc/rc.conf ]; then
. /etc/rc.conf
fi
fi


# set these to your outside interface network and netmask and ip
oif=tun0
onet=192.168.36.0
omask=24
oip=x.x.x.x


# set these to your inside interface network and netmask and ip
iif=vr0
inet=192.168.2.0
imask=255.255.255.0
iip=192.168.2.21

# for not the natd target is us but change this if you
# change that in natd.conf
natd_target=${oip}
work_vpnserver=y.y.y.y

INCOMING=4000
OUTGOING=8000
LOCAL=1000
SET=1

sysctl net.inet.ip.fw.enable=0
${fwcmd} -q flush
${fwcmd} -q table 1 flush
${fwcmd} -q table 2 flush
${fwcmd} -q table 3 flush
${fwcmd} -q table 4 flush

${fwcmd} table 1 add 10.0.0.0/8
${fwcmd} table 1 add 172.16.0.0/12
#${fwcmd} table 1 add 192.168.0.0/16
 # Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes
 # RESERVED-1, DHCP auto-configuration, NET-TEST, MULTICAST 
(class D),

 # and class E) on the outside interface
${fwcmd} table 1 add 0.0.0.0/8
${fwcmd} table 1 add 169.254.0.0/16
${fwcmd} table 1 add 192.0.2.0/24
${fwcmd} table 1 add 224.0.0.0/4
${fwcmd} table 1 add 240.0.0.0/4

# add legit sources of ssh.. DNS is not up yet so use IPs
# could add to /etc/hosts I guess.
#  myotherhouse.org
${fwcmd} table 2 add a.b.c.d
#  work
${fwcmd} table 2 add c.d.e.f/24
#  my vps
${fwcmd} table 2 add f.g.h.i/24

# add legit DNS tcp (zone) sources
#  my.dns.friends
${fwcmd} table 3 add m.n.o.p
#  my.dns.friend
${fwcmd} table 3 add q.r.s.t
#  my.vps
${fwcmd} table 3 add f.g.h.i

# Add our local networks here
${fwcmd} table 4 add 192.168.2.0/24
${fwcmd} table 4 add 172.16.15.0/24

# common spoofing code
# --- ALL PACKETS START HERE. 

${fwcmd} set disable ${SET}

# Stop localhost spoofing
${fwcmd} add 100 pass all from any to any via lo0
${fwcmd} add 200 deny log all from any to 127.0.0.0/8
${fwcmd} add 300 deny log ip from 127.0.0.0/8 to any

# If we've already decided on it. keep our word.
${fwcmd} add check-state

# Interception rules for external interfaces go here ---

# Internal traffic. generally don't care
# except to stop spoofing.
# make extra sure we don't block DHCP to our server (me)
# as initial request will be from 0.0.0.0/0

${fwcmd} add ${LOCAL} set ${SET} allow udp from any to any 67 
in recv ${iif}

${fwcmd} add allow udp from any 67 to any out xmit ${iif}

# other wise it has to be to 

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

[Julian Elischer]

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 layer order.
Do you confirm Luigi ?



​correct, it's not a matter of time but of placement
of the modules in the stack.

injection through bpf goes just above the
device driver, so there is no chance to see
bpf-generated packets.
For incoming traffic, bpf sees a copy, so the
original still goes through the stack,
but if you want to see it with ipfw you should
probably enable layer2 firewalling.
the ordering of the various special packet intercepts has always 
been an 'unsolved problem'.
Packets may be intercepted by several different agents in the 
networkng code. There are (at least):

bpf/tcpdump
divert
netgraph
ipfw/pf/ipf
if_bridge
vlan handling

And maybe others I didn't think of in the 20 seconds it took to write 
this.

Each of these has an equivalent outgoing injection point as well.
It is possible to make arguments for several different orders in which 
packets should hit these.


For example:
It makes perfect sense for tcpdump to see everything on the wire
regardless of what else is going on, however it may also make
sense to filter what gets to dhclient.  Unfortunately, they both use
the same way of getting packets.
Maybe the answer is to change dhclient to use a different
method.  When it was originally done only bpf existed.



cheers
luigi
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org





___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

Re: Questions about ipfw

[Julian Elischer]

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 properly established a tcp/21 port 
connection. Is this possible in
FreeBSD with ipfw?.
I believe not, though you maybe able to use nat to achieve this as it 
has an ftp module. I
t requires understanding the protocol.. ipfw tries to not know about 
protocols.



2.- I am a client A connecting to public ip 1.1.1.1 (for example) of host B. I 
want this packets at B to be redirected to host C
but changing the source address of A from that packets with the ip address of 
B. Later when B receives back the answer of C
that packets from the answer to be redirected to A changing B destination ip 
address to A destination ip address. So when telnetting
from client A to host B for example to port 5000, really, to be telnetting host 
C port 5000 for example and work this telnet properly from A.

The most important question is number two. Could you help me please?.

this is possibly doable with the NAT module or divert+natd.
We generally do not change the source address, but there are options 
for nat for reverse nating that may help.





Best regards.
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org





___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

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

[Julian Elischer]

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 module is loaded or statically compiled into a kernel.  And by
  default IPFW has only a deny ip from any to any rule if it is
  compiled without IPFIREWALL_DEFAULT_TO_ACCEPT option.  In this case,
  the default-deny rule can prevent rc.d scripts before rc.d/ipfw from
  working as described in the patch.

  To fix this, the patch turns IPFW off before running rc.d scripts at
  boot time, and enables it again in rc.d/ipfw script.

Hi,

I think this should be configurable, the change can be an unexpected for
someone.

it does open a window where there is networking but no firewalling.
given that a reboot is remotely detectable. (ping stops responding etc.)
there is a possibility that a targeted attack could include
use exploit ABC to cause a crash of the target and then strike with
exploit XYZ after target system reboots while the firewall is disabled.

I have not evaluated the danger of this window.


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

Re: ipfw named objejcts, table values and syntax change

[Julian Elischer]

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 permits writing this:

ipfw table tb1 create type cidr
ipfw add allow ip from table(tl1) to any
ipfw add allow ip from any lookup dst-ip tb1

ipfw table if1 create type iface
ipfw add skipto tablearg ip from any to any via table(if1)

or even this:
ipfw table fl1 create type flow:src-ip,proto,dst-ip,dst-port
ipfw table fl1 add 10.0.0.5,tcp,10.0.0.6,80 
ipfw add allow ip from any to any flow table(fl1)

all these changes fully preserve backward compatibility.
(actually tables needs now to be created before use and their type needs
to match with opcode used, but new ipfw(8) performs auto-creation
for cidr tables).

There is another thing I'm going to change and I'm not sure I can keep
the same compatibility level.

Table values, from one point of view, can be classified to the following
types:

- skipto argument
- fwd argument (*)
- link to another object (nat, pipe, queue)
- plain u32 (not bound to any object) (divert/tee,netgraph,tag/utag,limit)

There are the following reasons why I think it is necessary to implement
explicit table values typing (like tables):
- Implementing fwd tablearg for IPv6 hosts requires indirection table
- Converting nat/pipe instance ids to names renders values unusable
- retiring old hack with storing saved pointer of found object/rule
inside rule w/o proper locking
- making faster skipto

So, as the result, table will have lookup key type (already done),
value type ('skipto', 'nexthop', 'nat', 'pipe', 'number', ..) and some
additional restrictions (like inability to add non-existing nat instance
id).

This change will break (at least) scenarios where people are
using one table for both nat/pipe instances (and keep nat ids in sync
with pipe ones). For example:

ipfw table 1 add 10.0.10.0/24 110
ipfw table 1 add 10.0.20.0/24 120

ipfw add 100 nat tablearg from table(1) to any via vlanX in
..
ipfw add 500 pipe tablearg from table(1) to any via ix0 out

It looks like it is not so easy to bind values for given table to
different objects (or different tasks) (and lack of compatibility kills
hope for MFC).


I think this makes sense
I have myself been responsible for adding 'odd' usages to tables e.g. 
fwd tablearg
and have thought myself that really we need to be able to specify 
tables more specifically

so don't expect me to argue against this :-)



Ideas?






___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org



___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

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

[Julian Elischer]

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  X packet per 
Y*300 ms.   And the user need to understand how many millisecond each tick is .
on e can write an implementation that notes how much the calculation 
was off by for each tick and corrects the number for the next tick..


e.g. with Hz=10,   8pps should give sometimes 1ppt  and sometimes 0ppt 
but a simple calculation will always give 0 every tick
so you need to have some way of carrying forward 'unused bandwidth' so 
that  teh calculation looks like (over  a second)

ppt(real) ppt(int)
0.8 (0)
0.8+0.8=1.6 (1)
0.6+0.8=1.4 (1)  (subtract 1 from 1.6, and then add the 0.8 per tick)
0.4+0.8=1.2 (1)
0.2+0.8=1.0 (1)
0.0+0.8=0.8(0)
(sequence repeats)
0.8+0.8=1.6 (1)
0.6+0.8=1.4 (1)
0.4+0.8=1.2 (1)
0.2+0.8=1.0 (1)
0.0+0.8=0.8(0)

if you use any of the the int(ppt) in a tick you subtract the amount 
used. if not you allow it to build, up to some maximum value.


(sequence repeats)
0.8+0.8=1.6 (1)  (not used)
1.6+0.8=2.4 (2)  (not used)
2.4+0.8=3.2 (3)  (not used)
3.2+0.8=4.0 (4)  (4 packets allowed through further packets held or 
dropped)

0.0+0.8=0.8(0)
0.8+0.8=1.6 (1)  (not used)
1.6+0.8=2.4 (2)  (not used)
2.4+0.8=3.2 (3)  1 packet used.. 1.0 subtracted
2.2+0.8=3.0 (4)  (4 packets allowed through further packets held or 
dropped)

0.0+0.8=0.8(0)
etc.




So I will update it this weekend.



-Original Message-
From: owner-freebsd-i...@freebsd.org [mailto:owner-freebsd-
i...@freebsd.org] On Behalf Of 'Luigi Rizzo'
Sent: 29 May, 2014 23:20
To: freebsd-ipfw@FreeBSD.org
Subject: Re: kern/189720: [ipfw] [patch] pps action for ipfw

The following reply was made to PR kern/189720; it has been noted by
GNATS.

From: 'Luigi Rizzo' ri...@iet.unipi.it
To: bycn82 byc...@gmail.com
Cc: bug-follo...@freebsd.org
Subject: Re: kern/189720: [ipfw] [patch] pps action for ipfw
Date: Thu, 29 May 2014 17:17:59 +0200

  On Thu, May 29, 2014 at 11:06:27PM +0800, bycn82 wrote:
  
  
   -Original Message-
   From: Luigi Rizzo [mailto:ri...@iet.unipi.it]   Sent: 29 May, 2014 22:12  
 To:
bug-follo...@freebsd.org; byc...@gmail.com   Subject: kern/189720:
[ipfw] [patch] pps action for ipfw Hi,   I have looked at the update from
May 13th but it is not ready yet, the code assumes HZ=1000 so 1 tick=1ms.
  
   The translation can be done in userspace or in the kernel.
   I would prefer the latter.
   I see,
   If the HZ=3, that means every tick=333ms   And if the user wants to ??? 1
packet per 500ms???, then in the backend will not do the exactly the same as
what user expect.
  
   Actually the implementation should be ???packets per ticks???, so how
about this? Instead of translate it in codes. Why not update the document,
and explain it to the user in the document ?

  'Packets per tick' this is not a useful specification  since the tick's 
duration is
unknown to the user.
  Depending on the platform you can have HZ ranging from 15-20 (on windows)
to 1 or even more. Normal values are 100, 250, 1000 but  you just cannot
know what you are going to get.

  Yes there are rounding issues, and yes it is boring to write  code to handle
them.

  luigi
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org



___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

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

[Julian Elischer]

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  X packet per 
Y*300 ms.   And the user need to understand how many millisecond each tick is .
on e can write an implementation that notes how much the calculation 
was off by for each tick and corrects the number for the next tick..


e.g. with Hz=10,   8pps should give sometimes 1ppt  and sometimes 0ppt 
but a simple calculation will always give 0 every tick
so you need to have some way of carrying forward 'unused bandwidth' so 
that  teh calculation looks like (over  a second)

ppt(real) ppt(int)
0.8 (0)
0.8+0.8=1.6 (1)
0.6+0.8=1.4 (1)  (subtract 1 from 1.6, and then add the 0.8 per tick)
0.4+0.8=1.2 (1)
0.2+0.8=1.0 (1)
0.0+0.8=0.8(0)
(sequence repeats)
0.8+0.8=1.6 (1)
0.6+0.8=1.4 (1)
0.4+0.8=1.2 (1)
0.2+0.8=1.0 (1)
0.0+0.8=0.8(0)

if you use any of the the int(ppt) in a tick you subtract the amount 
used. if not you allow it to build, up to some maximum value.


(sequence repeats)
0.8+0.8=1.6 (1)  (not used)
1.6+0.8=2.4 (2)  (not used)
2.4+0.8=3.2 (3)  (not used)
3.2+0.8=4.0 (4)  (4 packets allowed through further packets held or 
dropped)

0.0+0.8=0.8(0)
0.8+0.8=1.6 (1)  (not used)
1.6+0.8=2.4 (2)  (not used)
2.4+0.8=3.2 (3)  1 packet used.. 1.0 subtracted
2.2+0.8=3.0 (4)  (4 packets allowed through further packets held or 
dropped)

0.0+0.8=0.8(0)
etc.

one does this with some form of fixed point arithmetic as floating 
point isn't used in the kernel.





So I will update it this weekend.



-Original Message-
From: owner-freebsd-i...@freebsd.org [mailto:owner-freebsd-
i...@freebsd.org] On Behalf Of 'Luigi Rizzo'
Sent: 29 May, 2014 23:20
To: freebsd-ipfw@FreeBSD.org
Subject: Re: kern/189720: [ipfw] [patch] pps action for ipfw

The following reply was made to PR kern/189720; it has been noted by
GNATS.

From: 'Luigi Rizzo' ri...@iet.unipi.it
To: bycn82 byc...@gmail.com
Cc: bug-follo...@freebsd.org
Subject: Re: kern/189720: [ipfw] [patch] pps action for ipfw
Date: Thu, 29 May 2014 17:17:59 +0200

  On Thu, May 29, 2014 at 11:06:27PM +0800, bycn82 wrote:
  
  
   -Original Message-
   From: Luigi Rizzo [mailto:ri...@iet.unipi.it]   Sent: 29 May, 2014 22:12  
 To:
bug-follo...@freebsd.org; byc...@gmail.com   Subject: kern/189720:
[ipfw] [patch] pps action for ipfw Hi,   I have looked at the update from
May 13th but it is not ready yet, the code assumes HZ=1000 so 1 tick=1ms.
  
   The translation can be done in userspace or in the kernel.
   I would prefer the latter.
   I see,
   If the HZ=3, that means every tick=333ms   And if the user wants to ??? 1
packet per 500ms???, then in the backend will not do the exactly the same as
what user expect.
  
   Actually the implementation should be ???packets per ticks???, so how
about this? Instead of translate it in codes. Why not update the document,
and explain it to the user in the document ?

  'Packets per tick' this is not a useful specification  since the tick's 
duration is
unknown to the user.
  Depending on the platform you can have HZ ranging from 15-20 (on windows)
to 1 or even more. Normal values are 100, 250, 1000 but  you just cannot
know what you are going to get.

  Yes there are rounding issues, and yes it is boring to write  code to handle
them.

  luigi
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org



___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

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

[Julian Elischer]

On 5/30/14, 11:06 PM, bycn82 wrote:

Hi ,
I am currently using HZ=2 in my testing environment, then the traffic in 
dummynet  by default delays for 500ms, the same reason for this PPS. Because it 
is based on the TICK.

How about introduce another option named PPT ? ( sounds familiar! ). and in the 
ipfw_chk,  PPS can just convert the duration from measurement `milliseconds` to 
`ticks`, and can reuse the logic of PPT. PPT technically is perfect. But for 
user, It is ugly. They need to know what TICK is ! anyway, at least user have 
an option to choose when they really need to be accurate.
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: 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  X packet per Y*300 ms.   And the user need to
understand how many millisecond each tick is .
on e can write an implementation that notes how much the calculation was
off by for each tick and corrects the number for the next tick..

e.g. with Hz=10,   8pps should give sometimes 1ppt  and sometimes 0ppt
but a simple calculation will always give 0 every tick so you need to have
some way of carrying forward 'unused bandwidth' so that  teh calculation
looks like (over  a second)
ppt(real) ppt(int)
0.8 (0)
0.8+0.8=1.6 (1)
0.6+0.8=1.4 (1)  (subtract 1 from 1.6, and then add the 0.8 per tick)
0.4+0.8=1.2 (1)
0.2+0.8=1.0 (1)
0.0+0.8=0.8(0)
(sequence repeats)
0.8+0.8=1.6 (1)
0.6+0.8=1.4 (1)
0.4+0.8=1.2 (1)
0.2+0.8=1.0 (1)
0.0+0.8=0.8(0)

if you use any of the the int(ppt) in a tick you subtract the amount used. if
not you allow it to build, up to some maximum value.

(sequence repeats)
0.8+0.8=1.6 (1)  (not used)
1.6+0.8=2.4 (2)  (not used)
2.4+0.8=3.2 (3)  (not used)
3.2+0.8=4.0 (4)  (4 packets allowed through further packets held or
dropped)
0.0+0.8=0.8(0)
0.8+0.8=1.6 (1)  (not used)
1.6+0.8=2.4 (2)  (not used)
2.4+0.8=3.2 (3)  1 packet used.. 1.0 subtracted
2.2+0.8=3.0 (4)  (4 packets allowed through further packets held or
dropped)
0.0+0.8=0.8(0)
etc.

one does this with some form of fixed point arithmetic as floating point isn't
used in the kernel.




So I will update it this weekend.



-Original Message-
From: owner-freebsd-i...@freebsd.org [mailto:owner-freebsd-
i...@freebsd.org] On Behalf Of 'Luigi Rizzo'
Sent: 29 May, 2014 23:20
To: freebsd-ipfw@FreeBSD.org
Subject: Re: kern/189720: [ipfw] [patch] pps action for ipfw

The following reply was made to PR kern/189720; it has been noted by
GNATS.

From: 'Luigi Rizzo' ri...@iet.unipi.it
To: bycn82 byc...@gmail.com
Cc: bug-follo...@freebsd.org
Subject: Re: kern/189720: [ipfw] [patch] pps action for ipfw
Date: Thu, 29 May 2014 17:17:59 +0200

   On Thu, May 29, 2014 at 11:06:27PM +0800, bycn82 wrote:
   
   
-Original Message-
From: Luigi Rizzo [mailto:ri...@iet.unipi.it]   Sent: 29 May, 2014 22:12  


To:

bug-follo...@freebsd.org; byc...@gmail.com   Subject: kern/189720:
[ipfw] [patch] pps action for ipfw Hi,   I have looked at the update

from

May 13th but it is not ready yet, the code assumes HZ=1000 so 1 tick=1ms.
   
The translation can be done in userspace or in the kernel.
I would prefer the latter.
I see,
If the HZ=3, that means every tick=333ms   And if the user wants to ???

1

packet per 500ms???, then in the backend will not do the exactly the

same as

what user expect.
   
Actually the implementation should be ???packets per ticks???, so how
about this? Instead of translate it in codes. Why not update the document,
and explain it to the user in the document ?

   'Packets per tick' this is not a useful specification  since the tick's 
duration

is

unknown to the user.
   Depending on the platform you can have HZ ranging from 15-20 (on

windows)

to 1 or even more. Normal values are 100, 250, 1000 but  you just

cannot

know what you are going to get.

   Yes there are rounding issues, and yes it is boring to write  code to

handle

them.

   luigi
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-

unsubscr...@freebsd.org

___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org






___
freebsd-ipfw@freebsd.org mailing list
http

Re: feature of `packet per second`

[Julian Elischer]

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 I don't use linux.. what is packet per second?.. does it 
report it or set a limit on it?


 bycn82

___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org




___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

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

[Julian Elischer]

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 !!!

So I assumed that currently it always using the same`chain`.
If so , is it better to separate the rules into multiple `chain`? 
for saying , chain1 chain2 chain3 chain4, and differnet `check 
point`s are going to use its own chain accordingly ?


you can do that with 1 chain, by using the 'skipto' command to make 
packets from different entry-points skipto different rule numbers.


Respect your effort, and I want to say `thanks` here, Thanks!

Best Regards,
Bill Yuan

On Wed, 16 Apr 2014 23:23:03 +0800, bycn82 byc...@gmail.com wrote:


Cool!
I just finished the overview of the source code,and finally 
understood the `for loop` in the ip_fw2.c roughly,
beside of the coding style,sorry for my ironic words, I want to ask 
whether my understanding is correct.


you wrap the packet/frame in the `check frame` or `check packet` 
which where invoked in the hook() function, and pass it into the 
chk() function
and the chk() function will check the `args` against the whole rule 
set.( the `chain` variable)


so my question is , does it mean that all the packet need to be 
checked against all the firewall rule, sorry I did not have time to 
check/understand how we generate the `chain` yet, If it is really 
working in this case, I cannot accept that personally!


according to the man page, we have 4 `check point`, I assumed that 
we have registered the hook() into 4 different places, for saying , 
if I have 10K lines of rules which are for 4st `check point` only, 
based on current logic, each packet/frame need to check against the 
rules for 4 times, and actually in the 1 2 3rd `check-point` ,the 
verification are not needed.  I hope i was wrong,


Can someone kindly explain the correct logic ? thanks very much!


On Wed, 16 Apr 2014 22:20:00 +0800, a...@freebsd.org wrote:


Synopsis: [ipfw] ipfw option `in` is not working on FreeBSD10

Responsible-Changed-From-To: freebsd-ipfw-ae
Responsible-Changed-By: ae
Responsible-Changed-When: Wed Apr 16 14:19:42 UTC 2014
Responsible-Changed-Why:
Take it.

http://www.freebsd.org/cgi/query-pr.cgi?pr=188543
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to 
freebsd-ipfw-unsubscr...@freebsd.org

___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org



___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

Re: ipfw dynamic rules

[Julian Elischer]

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 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 of) that needs
completely nuking.  It contains many factual errors as well as weird
notions, and will only tend to mislead you; consult ipfw(8) and prosper.
I'd say refer to the examples in rc.firewall but it too is in disrepair.

Firstly, I owe an apology to the doc crew, one of whom contacted me
privately to point out that the ipfw page has had quite a massaging
lately, and work is ongoing.  I'm sorry for not checking again first.

   I am working on a new rc.firewall that is much more efficient.
   the trouble is that the script to make it do what I want is a bit more
   complicated.
   I'll put it out for discussion later. maybe tonight.

Great.  Maybe my failed rc.firewall patch from '11 can still be useful.

rather than show the script (for now)
here's the generated output for a machine with 2 interfaces performing 
NAT on behalf of its

bretheren inside.

inside nets are covered in table1
table 2 specifies your DNS secondaries if you are serving dns as a 
primary.

table 13 is all the addresses you should never put out.. or get.
I run a very similar firewall on my machines but I'm generalising it.
curious to see what people make of it :-)
I haven't run this since I started rewriting the script so it may have 
errors.

count the following:
1/ the number of rules any given packet traverses
2/ the number of tests done on each packet
('from any to any ' is no tests, from me to any is 1 test, 'from me to 
you' is 2 tests.)
One if the things that drives me crazy with the current firewalls is 
that incoming and
outgoing packets from multiple interfaces traverse the same rules, in 
the same direction.
In this set each interface gets its own rules.. in the scripts they 
actually have their own files,

which are included to give this aggregate ruleset.

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
/sbin/ipfw table add 13 172.16.0.0/12
/sbin/ipfw table add 13 192.0.2.0/24
/sbin/ipfw table add 13 192.168.0.0/16
/sbin/ipfw table add 13 224.0.0.0/4
/sbin/ipfw table add 13 240.0.0.0/4

/sbin/sysctl net.inet.ip.fw.autoinc_step=2
/sbin/sysctl net.inet.ip.fw.default_to_accept=0
/sbin/sysctl net.inet.ip.fw.one_pass=0

/sbin/ipfw add 0 set 0 add pass ipv6-icmp from :: to ff02::/16
/sbin/ipfw add 2 set 0 add pass ipv6-icmp from fe80::/10 to fe80::/10
/sbin/ipfw add 4 set 0 add pass ipv6-icmp from fe80::/10 to ff02::/16
/sbin/ipfw add 6 set 0 add pass ipv6-icmp from any to any icmp6types 1
/sbin/ipfw add 8 set 0 add pass ipv6-icmp from any to any icmp6types 
2,135,136

/sbin/ipfw add 500 set 0 skipto 1000 ip from any to any in recv lo0
/sbin/ipfw add 502 set 0 skipto 1500 ip from any to any out xmit lo0
/sbin/ipfw add 504 set 0 deny all from 127.0.0.1 to any
/sbin/ipfw add 506 set 0 deny all from any to 127.0.0.1
/sbin/ipfw add 508 set deny all from any to ::1
/sbin/ipfw add 510 set deny all from ::1 to any
/sbin/ipfw add 512 set 0 skipto 2000 ip from any to any in recv xn0
/sbin/ipfw add 514 set 0 skipto 2500 ip from any to any out xmit xn0
/sbin/ipfw add 516 set 0 skipto 3000 ip from any to any in recv xn1
/sbin/ipfw add 518 set 0 skipto 3500 ip from any to any out xmit xn1
/sbin/ipfw add 520 set 0 deny ip from any to any
#lo0 rules
/sbin/ipfw add 1000 set 0 allow all from any to any
/sbin/ipfw add 1500 set 0 allow all from any to any

#xn0 input packets
/sbin/ipfw add 2000 set 0 skipto 2200 ip from any to MY_ADDR
/sbin/ipfw add 2002 set 0 reject ip from any to table(13)
/sbin/ipfw add 2004 set 0 allow udp from any to 255.255.255.255
/sbin/ipfw add 2006 set 0 allow udp from MY_NET to MY_BCASTADDR
/sbin/ipfw add 2008 set 0 drop ip from any to any
/sbin/ipfw add 2200 set 0 check-state
/sbin/ipfw add 2202 set 0 reject ip from table(13) to any
/sbin/ipfw add 2204 set 0 allow udp from any to any 53 keep-state
/sbin/ipfw add 2206 set 0 allow tcp from table(2) to any setup 53 
keep_state
/sbin/ipfw add 2208 set 1 allow tcp from any to any 
25,993,995,597,514,80,443 setup keep-state

/sbin/ipfw add 2210 set 0 allow udp from any to any frag
/sbin/ipfw add 2212 set 0 allow icmp from any to any keep-state
/sbin/ipfw add 2214 set 3 nat 1 ip from any to any
/sbin/ipfw add 2216 set 3 accept ip from any to table(1)
/sbin/ipfw add 2218 set 0 drop ip from any to any

#xn0 output packets
/sbin/ipfw add 2500 set 0 skipto 2700 ip from MY_ADDR to any
/sbin/ipfw add 2502 set 0 drop ip from not table(1) to any
/sbin/ipfw add 2504 set 0 reject ip from any to table(13)
/sbin/ipfw add 2506 set 3 nat 1 all from table(1) to any

Re: ipfw dynamic rules

[Julian Elischer]

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
/sbin/ipfw table add 13 172.16.0.0/12
/sbin/ipfw table add 13 192.0.2.0/24
/sbin/ipfw table add 13 192.168.0.0/16
/sbin/ipfw table add 13 224.0.0.0/4
/sbin/ipfw table add 13 240.0.0.0/4

/sbin/ipfw add 2002 set 0 reject ip from any to table(13)

Missing a couple martians, and this is a bit automatable.  It's sh,
after all.  Out of the script on one of my servers:


yeah though remember this is the output stream of the script, not the 
script itself..
it was loading it up from the small table I had in a here file in 
the script.. could easily be done from a separate file...


What I'm hoping for is to make a script set where you specify a 'type' 
for each interface, and the script builds itself..

e.g.

interfaces=xn0 xn1 tun0 tun1 lo0
fw_xn0_type=hostile nat
fw_xn1_type=trusted local
fw_tun0_type=trusted remote
fw_tun1_type=hostile nat_in

(lo0 need not be given a type)
this would firewall xn0 and tun1 and just do sanity testing on tun0 
and xn1


Julian






--
# A table for ipv4 martians
# Source: http://www.team-cymru.org/Services/Bogons/bogon-bn-agg.txt
# NOTE: Source file doesn't have terminating newline; be sure to add one!
mtable=100
bogfile=${mydir}/bogon-bn-agg.txt
if [ -r $bogfile ]; then
${ipfw} table ${mtable} flush
cat $bogfile | while read block ; do
${ipfw} table ${mtable} add ${block} ;
done
fi

# ... lots of stuff elided

# Ignore
${ipfw} add 1010 drop ip4 from table\(${mtable}\) to any
--


Handy to just be able to randomly fetch(1) a new file and let the fw
keep up.  Though watch out for that lacking trailing newline; I've
been left without 224.0.0.0/3 (save a slot, escew /4!) once or twice
from forgetting.




___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

Re: URGENT?

[Julian Elischer]

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 cause an awful lot of work to be 
done!

check state is a hash ;ookup and generally doesn't cause a lot of work.
it's about the equivalent of 2 simple rules I would guess so if you
save two rules by using check state,  then you win.




In my IPFW rule sets, I divide the work up by interface, and so 
there's a
check-state only for interfaces and directions (in vs. out) to 
which automatically

generated rules will apply.
I do the same.  first thing my rule set does is break the packet flow 
into N*4 separate sets of rules,
where N  is the number of interfaces. Each interface gets two sets of 
rules.. one for incoming
and one for outgoing. each of these it further divided into two 
smaller sets. One for
packets that are for or from THIS machine, and one that is for packets 
no for or from this machine)


incoming, for me
incoming NOT for me
outgoing from me
outgoing NOT from me

each of these sets can then have rules.
however since we know some of the information already it doesn't
need to be tested again so the rules there tend to be from any to any
because we already know who it's for (or from, depedning on the direction)

The problem is that this is still inefficient, because there's only 
one batch of
automatically generated rules, containing some that will never apply 
in certain
situations. My rule sets would be more efficient if I could divide 
the automatically
created rules into multiple batches, and do keep-state N and 
check-state N to check
only the batch that needed to be tested in a particular spot. This 
ought to be a relatively
easy patch, and I've thought many times about coding and submitting 
it. N would default
to zero, so the old behavior would be preserved if there was no N 
at the end so as not

to violate POLA.


I am working on a new rc.firewall that is much more efficient.
the trouble is that the script to make it do what I want is a bit 
more complicated.

I'll put it out for discussion later. maybe tonight.


Would like to see it!

see other emails for sample output.



--Brett Glass




___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

Re: ipfw dynamic rules

[Julian Elischer]

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.

Some things I abstract from this:

Use tables for lists of addresses where there's more than 5 or so.
I think tables are not as expensive as people think.. it's basically a 
single routing table lookup.
The funtionality added by allowing rule sets to stay, while changing 
behaviour makes
it worth using them even with 1 or 0 entries. We really should try 
profile ipfw..

I've never done that.. any profiling experts on the list?   :-)

I have not got my head fully around the lookup command yet or using 
interfaces

as table keys (I can't use that at work in 8.0 anyhow)
  ipfw add 100 ipfw skipto tablearg ip from any to any recv 
'table(10)' in
but we should see if it gives us any performance advantage over a 
simple hardcoded

filter like I used in my set.
I'd also like to have a number of local variables that you can set on 
each packet..

tags come close and maybe we should look to see what they can do for us,
but




Use skipto (judiciously)
In static rulesets, skipto is fast since they are not 'computed' the 
destination is cached, and

the cache is only cleared when new rules are added or removed.
using a tablearg for a skipto is unfortunately not so good as it can not
cache the result and must therefore actually traverse the set looking 
for the target.
(unless someone has added a table for rules that I missed since I last 
loooked.)





Use stateless and stateful rules appropriately
Basically in my experience, you can not use stateful behaviour on 
sessions that use NAT,

So you need to separate them out.
However you still get statefull behaviour because libalias uses a 
similar state table internally,
meaning that incoming packets must match some session already started 
in an outgoing direction,

or a specifically re-arranged translation.

I would really like to have multiple state tables as mentioned earlier..
another thing for the 'todo' file I guess, or maybe the ability to add 
an entry to a table dynamically..


 # stash away the address of our ntp servers in table 3
e.g. ipfw add 1000 table_add_dest 3 udp from me to any 123  out xmit xn0



Stick to some convention for tables - 13 for bogons, 0 for whitelist
RFC1918 addrs, 1 for whitelist public addrs, etc.


we could make such a standard doc.. and put it in the rc.firewall code 
speaks loudest.


Separate processing of packets coming in versus going out
I really think this is important. rule requirements are very different 
for in and out.
I further divide each into for us or for  other on incoming, and 
from us or

from other on outgoing. these rulesets are also usually very different.
One difficulty I have thugh is handling alias addresses, and packets 
that have

been redirected to go out an interface that doesn't match the from address
it has, even though it was locally generated.  I haven't found a way 
to say was locally generated
other than from me which is expensive.. me is a fairly expensive 
lookup,
and depends on a field that could have come from externally, (unless 
one has good  anti-spoof

rules in place early in the set I guess.

my own opinions below

I have a function in the shell script that loads tables fro named
files - the contents of tables change without changing the ruleset.

yes, a good reason to use tables.



Packets not destined for me will be processed again when they're
headed out - you can allow ip from any to any in after filtering for
the things you do/don't want for me - which is the norm for a
firewall router protecting internal nets.  This is, of course, after
early drop for traffic that is obviously bad


I only do this on 'trusted' interfaces.  I tend to trust on outgoing 
and filter on incoming more.
but it's an interesting thought. I hadn't really considered that. 
another nice -to-have
would be a filter point for routed traffic, just as it is routed.. 
(see the diagram in the man page).
it's possible we could simulateit on output if we could see if packets 
have been routed or not,

sort of the inverse of the locally generated test.




Use rulesets and matching tables to permit atomic table replacement
with rule swap
I do this.. at $JOB I just wrote an ipfw set that is the same 
regardless of which configuration
teh device is put in but rules come and go using set enable/disable as 
options are turned on/off.
but disabled rules still have a cost I believe as hey still need to be 
traversed,

unless someone has been very smart..


I also do policy-based routing with setfib and table arg, which means
that as conditions change, I can send traffic from a particular net
out a different interface.

It's a pitty that you need to do policy based routing only on input,
as output packets are already past their 

Re: URGENT?

[Julian Elischer]

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 I usually put the check-state quite early in my rule sets.
I am working on a new rc.firewall that is much more efficient.
the trouble is that the script to make it do what I want is a bit more 
complicated.

I'll put it out for discussion later. maybe tonight.


It should be the other way around. Once a flow has been learned it's
just a simple hash-table lookup once you hit the first stateful rule.
In pf most packets bypass the rules altogether.
___
freebsd-secur...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org



___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org

Re: ipfw dynamic rules

[Julian Elischer]

 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 of) that needs
completely nuking.  It contains many factual errors as well as weird
notions, and will only tend to mislead you; consult ipfw(8) and prosper.
I'd say refer to the examples in rc.firewall but it too is in disrepair.


I am working on a new rc.firewall that is much more efficient.
the trouble is that the script to make it do what I want is a bit more 
complicated.

I'll put it out for discussion later. maybe tonight.

as for the handbook pages.. after we see how the new firewall rules work
we can see about rewriting the page.

___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org