How to configure nat for interface which will be created later?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 It is possible to use non-existing interface name in via / xmit / recv option. It allows to write firewall which works with, say, VPN connection which is created AFTER firewall is loaded on boot. But "nat X config if " doesn't allow to use non-existing interface name! It looks like very strict limitation, as it doesn't allow to include VPN to nat config! Is here any solution for this problem? - -- // Lev Serebryakov -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJUz733XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePiT0P/A0QqEQD3vNBJYPvOEZwW2Vc 4xVlmMbqN0n/Wz+0bN/v8cIa5gMAYSwRGSyvE9D8FsbN7eXBe2J1DUjEq7E7er7E +jsr+bQTMpblvVBxCig+bNyjnDbFSqFzlU6ZyeBvYXbuhGmeaSnwAbfrl2eTGJ5X RlYjWRMmsUcJf+xp8xLifWoNC99/a4dyjTcmNiUd7ByrYVnnuriVCuM/NFRJPApS f2RUfoBhblDF9bC0NvnheIJpJ6sK12ZCTH4oRfRW4VEaKBpjpygH3WqmGqTUas9C rOEpE7HUA7LjwFqhi2TGbreZZX4EFVztWOUi9ufKoHX93264rtIv8EMu/LtKjuyy LrbBDl5zH6A881eTrQdZXjsG87VSwZA3ctlPjg/trw8UX0qtG3MsbfgIgp47srVK gMKmVMt0kpzHs3n7rmk8On5ELwUkbjMOPFsg1JXfhNUGelJJ+pMXBm0kaIpiHdzT 6tkSgfrvOJEziFmDF5hCcfHPzMGXJqiMCFqvrX7IsEmx9VLsLKVs2NoX7D+yu4T/ /+SAffJ4OMC22SyDHpaSfZLZTN1eHquepnpvGWYo7aUJm0kQ15Wp8qTMqQ4MFPMz GFoOuJdPDqhd96aTKYI+UYYRC51lqyCiJxmETqMWOgeT3muVsya2PRrVYALEy38H enNnWTWHiw2+3HMWMhtl =V2ZH -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: How to configure nat for interface which will be created later?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02.02.2015 21:12, Lev Serebryakov wrote: > It is possible to use non-existing interface name in via / xmit / > recv option. It allows to write firewall which works with, say, > VPN connection which is created AFTER firewall is loaded on boot. > > But "nat X config if " doesn't allow to use non-existing > interface name! It looks like very strict limitation, as it > doesn't allow to include VPN to nat config! > > Is here any solution for this problem? Looking at "sbin/ipfw/nat.c:166" and "sys/netpfil/ipfw/ip_fw_nat.c", it looks like this userland check is too restrictive. But I'm not sure, that I'm right... - -- // Lev Serebryakov -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJUz7+5XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePL6kP/2CFIvPrqGhYISH1z420qAoK r5oE5SwlFcwARQONqUuizTsmlqt4UIP8xWGxb7YWzQgkbXVlht1zgBvby3xVzlJo zoXfSsz9CN3GJShBkuCcXG0pHh1UpFrFYR1RN8uLHvsm6i+Hq5nZuaBSio+eaD1+ x/TmLdz+zVmQGO6GWscnN21A0bRP49Q4KJKZlkklAhZ0xVU9QQ77Mc3vCMOk0dGA ObAeFu8fWqQHVGCeQppxJkLynWrhnHyyTeJvEvewGC+aWCu9H4xxa5oTEKFytQWc ImQcfzkqgnk5U1gPsND89RXp8gxqWzV9TbRXF7cV2hHFbs4inJAUw+n2ammM4iFR xg2BJlSxcaCx2xYtERqSRT6MRFR1zI1q/hEOW6puyJ611ILQ+TQRp5zrhnY1RkSe qtVrpgtchJsFK1759PreVqd6dAbmfjhnklgdoL6J6r+LjNpEOI+2t0O+4sudG0M3 T1unH0K8IcdRg67LYJW371pUn5V4qIhnur8YXuXp24vuHvDZQmhZRdRDrpfESl+s f97H06jGA9FIRS05o0PMIGUtpI48S7XjoaobOcb1CjVTfyItWMjAvK7TkpF1zmxD z8AOdpHDZezf/TVDGKNxBLrQzK9hMOoUz9PKQA7JkbfDHmT6/zwDTBYnNjSW+VuS ExLECR6f/seC3nEW6tek =Vyhu -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"
[RFC][patch] Two new actions: state-allow and state-deny
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
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
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 skipto 2010 from any to any keep-state
add 2010 nat NR from any to any out // Note this "out" in out section!
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
(b) Adding "allow keep-state" to _IN_ rules on _internal_ interfaces
to check this states AFTER _IN_ nat on _external_ interfaces.
I don't like both of them. First one is not very clear and needs
additional "out" option on outbound NAT rule. Second one requires to
have "allow keep-state" and "check-state" rules in different parts of
firewall, on different interfaces, which is not very clear too and
needs additional conditions for "allow keep-state" if you don't want
stateful firewall for internal networks and only want states for
external traffic.
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?
- --
// Lev Serebryakov
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)
iQJ8BAEBCgBmBQJUz81EXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF
QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePkhwQAJg4s1Ipomi0lZTqa8pklExD
GHvkeuVdm1RSakolwHf8M26a+Xg1zlIm0tD2PQ18FkaA1QTjwai7kyKu2SwhsvkF
P7B3GE33Pj4dhMzhpnmSnxcjLZEAENENzAOnGBN47NM617KOkJmyRmH54RO8xFI8
UbctlfiWC0ECujlWC4HcLthlrI3ZemqeFK1llzQ+k0LgUDQ8eegFmrLCbMVbVKxJ
4HACPQzzPwzabZE+kifE1KDnOEthEuTXuMpL6pS98s8w+b92TFJsS40DqngWNuqv
M2QCCJbLZRwoDRTkf3H8AlbdIk94CPFjJkmZd86ZUpKF3rVJ7VICH7SkV90P1hlm
yRc/26jX2LvqyyKgxMDQ4UpJuSikxASHx/3mDOV83snxlXtwW0or6f+XSW1QVFFt
2OCo6DmwclQ2HzBaomy0QKqlKq09VzHJdEBtfsyBqKyQP2UG3/CDj6rwqc564rOb
MDJFDtsMsquOgJTBSYLcAQhc8v9I3HUuELT/eyo3YCCrPKAAPtV89jWZ2dI+np3h
utaVJxJ4qSyVp5R3H2MTvWdk1PPptygxx0UHMVyNTgSnsbczNsywWzELoOzTzEZn
XS352D2dWXsvFV07cwtHovnY+vCKOXVI2ljJ6uHwZZlisJg4M+o80LChHT5jQ6nw
9DVWmu2YK6nC7aJI6Fy7
=TMJo
-END PGP SIGNATURE-
Index: sbin/ipfw/ipfw.8
===
--- sbin/ipfw/ipfw.8(revision 278021)
+++ sbin/ipfw/ipfw.8(working copy)
@@ -932,6 +932,26 @@
.Ed
.Pp
This cosmetic annoyance may be fixed in future releases.
+.It Cm state-allow
+Create dynamic rule which acts as
+.Cm allow
+rule when checked with
+.Cm check-state
+action.
+When this action is taken directly, search continues with the next rule.
+This action implies
+.Cm keep-state
+instruction.
+.It Cm state-deny
+Create dynamic rule which acts as
+.Cm deny
+rule when checked with
+.Cm check-state
+action.
+When this action is taken directly, search continues with the next rule.
+This action implies
+.Cm keep-state
+instruction.
.It Cm tee Ar port
Send a copy of packets matching this rule to the
.Xr divert 4
Index: sbin/ipfw/ipfw2.c
===
--- sbin/ipfw/ipfw2.c (revision 278021)
+++ sbin/ipfw/ipfw2.c (working copy)
@@ -264,6 +264,12 @@
{ "setdscp",TOK_SETDSCP },
{ "call", TOK_CALL },
{ "return", TOK_RETURN },
+ { "state-accept", TOK_STATE_ACCEPT },
+ { "state-pass", TOK_STATE_ACCEPT },
+ { "state-allow",TOK_STATE_ACCEPT },
+ { "state-permit", TOK_STATE_ACCEPT },
+ { "state-deny", TOK_STATE_DENY },
+ { "state-drop", TOK_STATE_DENY },
{ NULL, 0 } /* terminator */
};
@@ -1584,6 +1590,14 @@
bprint_uint_arg(bp, "call ", cmd->arg1);
break;
+ case O_STATE_ACCEPT:
+ bprintf(bp, "state-allow");
+ break;
+
+ case O_STATE_DENY:
+ bprintf(bp, "state-deny");
+ break;
+
default:
bprintf(bp, "** unrecognized action %d len %d ",
cmd->opcode, cmd->len);
@@ -3807,6 +3821,16 @@
Re: How to configure nat for interface which will be created later?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02.02.2015 21:19, Lev Serebryakov wrote: >> It is possible to use non-existing interface name in via / xmit / >> recv option. It allows to write firewall which works with, say, >> VPN connection which is created AFTER firewall is loaded on >> boot. > >> But "nat X config if " doesn't allow to use non-existing >> interface name! It looks like very strict limitation, as it >> doesn't allow to include VPN to nat config! > >> Is here any solution for this problem? > Looking at "sbin/ipfw/nat.c:166" and > "sys/netpfil/ipfw/ip_fw_nat.c", it looks like this userland check > is too restrictive. > > But I'm not sure, that I'm right... To be honest, I don't understand code in sbin/ipfw/nat.c:80 (function set_addr_dynamic()) at all! First of all, it enumerates though interface list to find interface and store it index to "ifIndex" and MTU to "ifMTU" variables. After that, it continues to enumerate SAME data structure to find address. But "ifIndex" and "ifMTU" are never used again! - -- // Lev Serebryakov -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJUz9GsXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePdF0QALinIRoUkZ1uUAiAUAbLHaGe JB6rKraVUt3ps37mUgiWFD6YaiVDA+lTgPpm85aRtc21b+I7CAPCu6urZqhlZtRc DMO/JCPLa6EPx2o2TA6UhCJ5AKHtmRb50V6KhhDXrR1NaZCQ+a5PZZY9D/MhHYa2 O/F8fFXr+9MHeocQ2ZjYvImjIVTM/nSGRLleq0M539I6Vsa/Eblw2fe/8ugSmTjB eKFuzxXM37QAcpj6exhuRIOxQy8Rp9WVCsm+j6RaMd3L5AjUNd+EP4Cjz3z9YlEx R2uJWlXwfxKo4wkCBC65R+IuHiRoQOr6COERKijmReAEBZ9w9CkpTbZ1Jv9Ri/bq WcanR8o+GO30QKXO1gLckTdikeDKLxsIfuf1CAgJivf9HSV8UzKy6ktdEF7rWP3d WoBmzpsoGpdzNhgCW2Px1J4ZXzM2mfzxxJCulFYfrapCC3G+fQ42ZmU5QXE9w6LZ xdMB5MivxSjxrnrFRAheG0BCaIJhR9FwT1HKulO/cxBZ21lcoe+aBwhOOr3GRC3u 70g2VX5Ey6V7PFWNsglaFKStQdAgavUqfGLBaMmnvqTT3jljPzdkQQrP7eBdwuVL sW8JgA2ksh/lHHIm0NYc1yMIYxrW+yB7tsVLtygTn+K0aQMXPTMB70Z05TWlCb2H tgGvKYbyYcm8X213znx/ =q9nY -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
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}
#
Re: [RFC][patch] Two new actions: state-allow and state-deny
*cool, I like this, it got some points.*
*though the email is too long to be read.*
On 3 February 2015 at 14:44, Julian Elischer wrote:
> 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
>
> # Inte
