Re: Question that has dogged me for a while.
> 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.
> 11:19:16.369337 IP 192.168.10.40.60924 > 70.169.168.7.11443: Flags [S],
> seq 292171178, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK],
> length 0
> 11:19:16.369433 IP 192.168.10.40.60925 > 70.169.168.7.11443: Flags [S],
> seq 2666765817, win 8192, options [mss 1460,nop,wscale
> 8,nop,nop,sackOK], length 0
> >> 11:19:16.369502 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.369511 IP 192.168.10.40.60925 > 192.168.10.100.11443: Flags
> [S], seq 2666765817, win 8192, options [mss 1460,nop,wscale
> 8,nop,nop,sackOK], length 0
>
> But since the gateway emitted the packet back on the wire *without*
> remapping the source address (to itself) it doesn't match on the client
> box 'cause there's no way back for it.
Yep.
>
> There has to be a solution to this somewhere and I'm obviously missing
> it. :)
>
> --
> Karl Denninger
> k...@denninger.net
> /The Market Ticker/
> /[S/MIME encrypted email preferred]/
This is the classical "Loopback Nat Problem" of accessing machines
behind a NAT device that does not do the proper NATTing and
routing of these packets. Many small consumer routers got this
wrong for years, just like most ipfw code I have seen.
Most of the consumber devices have been fixed. The trickery is
you need to NAT packets coming from the inside destined for the
outside IP into the internal IP. That internal box MUST route
back via the NAT device, so the NATTED addresses for these
packets must be the inside IP of the router.
Your code looks to get this mostly right, but I think you have
missed something someplace. I dont use kernel nat, and it looks
like you do so you well have to adjust these a little.
inside_ip_router="192.168.10.40"
outside_ip_router="70.16.10.1"
inside_ip_webserver="192.168.10.100"
#natd-vmxZ.conf should just be an empty file for this type of nat
/sbin/natd -f /etc/firewall/natd-vmxZ.conf -port -alias_address
${192.168.10.40}
Something like
# This takes inside traffic to outside port 80 address and
# remaps it to inside IP of router to send to web ser
Re: Question that has dogged me for a while.
[ Charset UTF-8 unsupported, converting... ]
> On Thu, May 4, 2017 at 9:22 AM, Karl Denninger 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:
> >
> > 11:19:16.369337 IP 192.168.10.40.60924 > 70.169.168.7.11443: Flags [S],
> > seq 292171178, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK],
> > length 0
> > 11:19:16.369433 IP 192.168.10.40.60925 > 70.169.168.7.11443: Flags [S],
> > seq 2666765817, win 8192, options [mss 1460,nop,wscale
> > 8,nop,nop,sackOK], length 0
> > >> 11:19:16.369502 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.369511 IP 192.168.10.40.60925 > 192.168.10.100.11443: Flags
> > [S], seq 2666765817, win 8192, options [mss 1460,nop,wscale
> > 8,nop,nop,sackOK], length 0
> >
> > But since the gateway emitted the packet back on the wire *without*
> > remapping the source address (to itself) it doesn't match on the client
> > box 'cause there's no way back for it.
> >
> > There has to be a solution to this somewhere and I'm obviously missing
> > it. :)
>
>
> ?You need to do a double-NAT (or hairpin-NAT or whatever you want to call
> it), where you first NAT the destination address on the incoming interface
> which will initiate the routing decision for where to send the packet next,
> then NAT the source address on the outgoing interface (which can be the
> same interface) in order to get the return packets sent back to the correct
> gateway.
>
> Something along the lines of:
>
> ipfw nat 100 blah blah blah
> ipfw nat 200 blah blah blah
>
> ipfw add nat 200 tcp from 192.168.0.0/16 to 70.16.10.1 80 in recv
> ipfw add nat 100 tcp from 192.168.0.0/16 to 192.168.1.1 80 out xmit
>
> ipfw add nat 100 tcp from 192.168.1.1 80 to 70.16.10.x in recv
> ipfw add nat 200 tcp from 70.16.10.1 80 to 192.168.0.0/16 out xmit
> ?Note: I've only ever done this with non-stateful rulesets. Once you add
> state keeping, NAT configuration becomes horribly, horribly complex with
> IPFW. Stateless rules are super easy, though. :)
> ?
This looks good too. Note that you can do this inside loop back NAT
in a stateless manner, your only doing this to make it work, your not
trying to do any keep state type protection. Then leave the NAT that
is going out to the world as a keep state type NAT.
I am a strong advocate of s
Re: Question that has dogged me for a while.
>
> 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. Upda
Re: Question that has dogged me for a while.
> On 5/4/2017 13:47, Rodney W. Grimes 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 ... > > It is almost impossible to remotly debug this type of stuff without a > > complete and full picture of all elements involved. > > As a minimum: > > ifconfig -a > > ipfw -a list > > sysctl net.inet.ip.fw.one_pass > > sysctl net.inet.ip.forwarding > > > > I know this can be made to work, I think even dd-wrt has it right > > And here is a good jumping off point from a very quick google: > > http://www.nycnetworkers.com/real-world/nat-reflectionnat-loopbacknat-hairpinning/ > > > root@IPGw:/usr/local/etc # ifconfig -a > lo0: flags=8049 metric 0 mtu 16384 > options=63 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 > inet 127.0.0.1 netmask 0xff00 > groups: lo > nd6 options=21 > ue0: flags=8843 metric 0 mtu 1500 > options=80009 > ether b8:27:eb:4e:88:64 > inet 192.168.10.200 netmask 0xff00 broadcast 192.168.10.255 > media: Ethernet autoselect (100baseTX ) > status: active > nd6 options=29 > ue1: flags=8843 metric 0 mtu 1500 > options=8000b > ether 00:50:b6:5d:1d:9f > inet 70.169.168.7 netmask 0xff80 broadcast 70.169.168.127 > media: Ethernet autoselect (100baseTX ) > status: active > nd6 options=29 > ue0.3: flags=8843 metric 0 mtu 1500 > ether b8:27:eb:4e:88:64 > inet 192.168.4.200 netmask 0xff00 broadcast 192.168.4.255 > groups: vlan > vlan: 3 vlanpcp: 0 parent interface: ue0 > media: Ethernet autoselect (100baseTX ) > status: active > nd6 options=29 > > root@IPGw:/usr/local/etc # ipfw -a list > 0010014 1042 allow ip from any to any via lo0 > 00200 00 deny log ip from any to 127.0.0.0/8 > 00300 00 deny log ip from 127.0.0.0/8 to any > 00400 00 deny log ip from any to ::1 > 00500 00 deny log ip from ::1 to any > 02000 00 allow ip from 192.168.100.1 to any in via ue1 > 02010 00 deny log ip from 192.168.0.0/16 to any not ipsec in > via ue1 > 02020 00 deny log ip from 70.169.168.0/25 to any in via ue0 > 03000 00 deny log ip from 70.169.168.0/25 to any recv ue0 > 04000 00 deny log ip from table(22) to any recv ue1 > 04010 00 deny ip from any to > 114.215.179.104,122.226.84.253,122.248.234.207,167.206.87.147,168.1.83.89,175.41.238.100,176.58.116.160,202.96.134.133,203.143.89.106,220.181.111.147,23.234.53.61,23.234.53.67,46.137.188.54,50.19.254.134,50.7.114.59,50.7.124.48,50.7.176.18,50.7.235.90,50.7.44.82,61.188.37.216,68.192.249.119,74.125.31.99 > 04020 00 deny log ip from > 218.90.0.0/16,218.91.0.0/16,218.92.0.0/16,218.93.0.0/16,218.94.0.0/16 to > any via ue1 > 05000 00 deny log ip from > 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 to any not ipsec recv ue1 > 05010 00 deny log ip from > 0.0.0.0/8,169.254.0.0/16,192.0.2.0/24,224.0.0.0/4,240.0.0.0/4 to any > recv ue1 > 06000 8726 10333291 nat 100 ip4 from any to me recv ue1 > 07000 00 check-state :default > 0800021 1064 nat 200 ip4 from 192.168.0.0/16 to 70.169.168.7 Where is the other half of nat 200? This is from inside to outside IP, there needs to be a return nat occuring to de Nat the packets ipfw add 8000 nat 200 ip4 from 192.168.0.0/16 to 192.168.10.200,192.168.4.200 It takes 2 rules to the same NAT to have working NAT usually, one for outbound packets, and one for inbound packets (relative to the NAT instance). Do we see atleast the packets this nats on the wire with tcpdump? > 08001 4834 264258 nat 100 ip4 from 192.168.0.0/16 to any xmit ue1 > 08009 00 deny log ip4 from 192.168.0.0/16 to any xmit ue1 > 08010 4836 264410 allow ip4 from 70.169.168.0/25 to any xmit ue1 > 08011 00 allow log ip from 192.168.10.200 to 192.168.0.0/16 > dst-port 2552 > 08020 5374 306553 allow ip from 192.168.0.0/16 to any recv ue0 > 08030 2 104 allow ip from 192.168.4.0/25 to any recv ue0.3 > 08500 00 deny log ip from 192.168.0.0/16 to any xmit ue1 > 09000 17823 20712366 allow ip from any to 192.168.0.0/16 > 22000 00 allow tcp from any to any established Interesting that the count on this is 0?
Re: Rule action "queue" also causes search to terminate, yes?
-- Start of PGP signed section. > The ipfw(8) man page explicitly states that rule actions: > > * allow | accept | pass | permit > * deny | drop > * divert > * reset | reset6 > * unreach | unreach6 > * abort | abort6 > > cause "search terminat[ion]". > > > The description for "queue," however, is: > > queue queue_nr > Pass packet to a dummynet ``queue'' (for bandwidth limitation > using WF2Q+). > > > In particular, there is no statement that "The search terminates" (as > there is for the above-cited rule actions). > > My (admittedly quick) reading of the code suggests that for the "queue" > rule action, the search does, in fact, terminate. This also seems to be > borne out by empirical evidence (now that I have a "queue" rule in my > active set of rules on my laptop): > > ... > 04300 108692998 skipto 6 udp from 192.168.23.119 to any dst-port 53 > keep-state :default > 04400 00 deny log udp from any to any dst-port 123 iplen 0-75 > 04500 15511780 skipto 6 udp from 192.168.23.119 to any dst-port 123 > keep-state :default > 04600 00 skipto 6 udp from any 123 to 255.255.255.255 > dst-port 123 keep-state :default > 04700 00 skipto 6 udp from 192.168.23.119 to any keep-state > :default > 04800 00 deny log ip from any to any > 6 35471 18109017 allow ip from any to any in > 60100 32582 5110013 queue 1 ip from any to any out > 65535 1 340 deny ip from any to any > > > So: > * Is my reading of the code -- that "queue" (also) casues the search to > terminate) correct? > > * If so, is a change to the ipfw(8) page (to state that explicitly) > warranted? (As someone who was recently trying to figure some of this > stuff out, I believe that such a statement -- if it is true! -- would > have been helpful for me.) I believe that the behavior of a queue is that of a pipe, and the "termination" condition is dependent on net.inet.ip.fw.one_pass. You are correct though the manual page does not document this for a queue. At least any place I could find. -- Rod Grimes rgri...@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: manpage: semantics of "receive" and "xmit" interfaces
> On 09.01.2018 12:28, O. Hartmann wrote: > > In section RULE OPTIONS, there is recv|xmit|via explained (a bit). There is > > also an example: > > > > ipfw add deny ip from any to any out recv ed0 xmit ed1 > > > > Can someone explain a bit more what the semantics of these is? I get > > especially > > confused by the subsequent blocks of text following the line I mentioned > > above. > > Since not everybody using FreeBSD is capable of studying the kernel > > sources, I > > have difficulties to put those statements in line with a visualization of > > the > > packet flow. A local host receiving a packets destined for the local host > > can > > not have xmit interface? If I imagine, that the recv interface might be the > > interface adjacent directly to the in/out port depicted in section PACKET > > FLOW > > it doesn't give me any idea why there is no xmit interface. > > When your system has two interfaces ed0 and ed1, and it acts as router, > a forwarded packet can be checked by firewall two times: > > 1. When a packet is received on ed0 interface, mbuf associated with this > packet gets a property "receiving interface". This packet is checked for > inbound direction and can be matched by "in" and "recv ed0" opcodes. in, recv and via options > If it was not dropped by rules, it will go through IP stack and can be > forwarded according to routing table via interface ed1. > > 2. When the routing decision was made (i.e. outbound interface is > determined) a packet checked by firewall again, now for outbound > direction. And it can be matched by "out" and "xmit ed1" opcodes. The in, recv and via options > opcode "recv ed0" still can be matched too, but "in" opcode will not > matched. > > A packet destined for local host is consumed by local IP stack and will > not forwarded. It is checked by firewall only one time (usually). Thus > it can not have xmit interface. And a packet generated localy would not have a recv interface. > -- > WBR, Andrey V. Elsukov > -- Rod Grimes rgri...@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
> 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? -- Rod Grimes rgri...@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: Missing sysctl net.inet.ip.fw.dyn_keep_states on FreeBSD 11.2
> Hello, > > I upgraded my desktop system from FreeBSD 11.2-BETA1 last week, and I found > the > sysctl 'net.inet.ip.fw.dyn_keep_states' got removed. I upgraded it again to > FreeBSD 11.2-BETA2 today, and I still could not find it. Currently I rely on > both 'net.inet.ip.fw.default_to_accept=1' and > 'net.inet.ip.fw.dyn_keep_states=1' > to be able to reload firewall rules with 'service ipfw restart' without > breaking > existing TCP connections. As this sysctl variable is still mentioned in > ipfw(8) > man page, will it be brought back in future versions, or there will be an > alternative solution for firewall rules reload? As a follow up to this discusion, there has been a merge of code into the stable/11 branch that should be in the 11.2-BETA3 build that corrects this missing sysctl, could you please test this build when it comes out and provide feed back to how it works for you. Thanks, -- Rod Grimes rgri...@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 uid/gid debugging, tcpdump relation with ipfw and how to block direct access to port 25
> On 04.07.2018 15:28, supportsobaka--- via freebsd-ipfw wrote:
> > Could you please explain whether tcpdum should see a packet dropped
> > on ipfw?
In general NO, ipfw well not see a packet that is "deny" or "drop"
by ipfw, as the bpf code is called after ipfw.
>
> tcpdump is not related to ipfw.
> ipfw(4) has ability to send packets,
> that are matched by rules with "log" opcode to special ipfw0 pseudo
> interface. This interface can be created at run-time. Then, you can add
> "log" keyword to the deny rule and see such packets in `tcpdump -ni
> ipfw0` output.
One of the reasons to have the ipfw0 pseudo device is so that these
dropped packets can be seen by tcpdump.
> Simple example:
>
> # ifconfig ipfw0 create
> # ipfw add 1 deny log icmp from me to any
> # ping 127.1
> # tcpdump -ni ipfw0
> 12:21:19.222133 IP 127.0.0.1 > 127.0.0.1: ICMP echo request, id 64151,
> seq 0, length 64
> 12:21:20.230762 IP 127.0.0.1 > 127.0.0.1: ICMP echo request, id 64151,
> seq 1, length 64
>
> > Does it look before or after ipfw? tcpdump -vvv port 25
> > shows nothing when port is blocked on ipfw (security log shows droped
After ipfw
> tcpdump works at layer2 level. The kernel sends packets to BPF when it
> goes through ethernet handling routines.
> ipfw(4) usually works at layer3 level, i.e. when Ethernet layer already
> did, or not yet did its work. Anyway, you can not see dropped packets if
> you did not prepared to this like I described.
IIRC tcpdump hooks at the same points as ipfw, just ipfw hooks first.
ipfw(3) works at both layer2 and 3 depending on the rule as you can
do mac level filtering, and there is even a layer2 option keyword
so you can control if your rule is applied at when the packet
traverses certain points in the kernel.
NOTE that ipfw can see the same packet up to 4 times so you have
to be careful if you turn on certain options and start to do layer2
filtering. There is a description of this in the man page ipfw(4)
in the PACKET FLOW section.
> > packets). Also, is there a way to to see uid/gid on the packet in
> > ipfw log? Alternatively, can tcpdump show uid/gid of the packet
> > (before ipfw)? I don't see uid/gid when use tcpdump -vvv port 25. Is
> > there a way to understand if packet does't have uid/gid or it just
> > not shown? I can't figure out a good rule to protect access to port
>
> tcpdump has not such ability or knowledge.
And it appears as if ipfw does not log this info when it does have
it avaliable and a rule that matches with the log option is present.
This should probably be added as a feature to assist in debugging.
> > 25 for other than sendmail (yep, native sendmail). The obvious
> > ${ipfw} add allow tcp from me to any 25 out gid smmsp setup
> > keep-state :emailfromme doesn't work (email is not sent out,but
> > dropped on the ipfw by the last deny rule). Seems like the packet
>
> how do you test this?
>
> > sent by sendmail doesn't belong to snmmsp group. I have tried gid
> > operator gid mail gid smmsp gid wheel - won't help. How to debug?
>
> --
> WBR, Andrey V. Elsukov
--
Rod Grimes rgri...@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 managing rules - best practice?
> Wed, 5 Sep 2018 18:33:58 +0300 - "Andrey V. Elsukov" > : > > > On 05.09.2018 12:28, Ole wrote: > > > I understand, that this connections get broken because the dynamic > > > rules get flushed with the `ipfw -q -f flush` command. But > > > commenting this command out results in a continuously growing rules > > > table. > > > > > > With the `ipfw -d list` command I can see the dynamic rules. > > > Is there a way to flush the rules but not the dynamic ones? > > > Or to add them again after flush? > > > > There is net.inet.ip.fw.dyn_keep_states sysctl variable. It allows to > > keep dynamic state when parent rule is deleted. But you need to use > > default_to_accept firewall to make it working. > > I plan to reimplement this feature to be more useful and work with any > > rules, and not only with "allow" rules. > > Ah, thank you very much. This is exactly what I was searching for. I > deployed it to some machines and it is working well. > > One Question: I have lots of hostname dependend rules in lots of jails. > Do you think it is OK to reload the ruleset every 5 min by cron to > re-resolv the hostnames? Your milage may vary depending on what your doing, but here are some ideas. My prefered method for dealing with lots of IP/hostnames in ipfw rule sets is to place them all in different tables and then just flushing and rebuilding the tables rather than the whole rule set. I can think of using the value in the table to indicate what generation that IP belongs to and doing some fancier things that would do the lookups and add them to the table as generation n++, then when finished iterate over the table and delete all generation n IP's, then bump the generation number which can be stored in the table on 0.0.0.0/32 (not default, but literaly the all 0's address, or some other magic token. I have done that type of thing from a C program for other usses, not for name resolving. -- Rod Grimes rgri...@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 firewall stock rule types ?
> > I'm setting up a new server, from scratch, and I find that it's always > best to review relevant sections of the Handbook when doing so, especially > if one hasn't done this fopr a long time, which I haven't. > > This page has me a bit puzzled: > > > https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls-ipfw.html > > This page says that the stock ipfw firewall rulesets are as follows: > > open: passes all traffic. > client: protects only this machine. end node > simple: protects the whole network. router > closed: entirely disables IP traffic except for the loopback interface. > workstation: protects only this machine using stateful rules. > UNKNOWN: disables the loading of firewall rules. > ... > > I'd just like to know what the differences are between "client" and "simple". Someone could update the handbook to indicate that client is an end node, and that simple is for a router. > > Can anyone explain that to me, briefly? >From /etc/rc.firewall the comments on each of client and simple help to cover the difference: [Cc][Ll][Ii][Ee][Nn][Tt]) # This is a prototype setup that will protect your system somewhat # against people from outside your own network. # # Configuration: # firewall_client_net: Network address of local IPv4 network. # firewall_client_net_ipv6:Network address of local IPv6 network. [Ss][Ii][Mm][Pp][Ll][Ee]) # This is a prototype setup for a simple firewall. Configure this # machine as a DNS and NTP server, and point all the machines # on the inside at this machine for those services. # # Configuration: # firewall_simple_iif: Inside IPv4 network interface. # firewall_simple_inet:Inside IPv4 network address. # firewall_simple_oif: Outside IPv4 network interface. # firewall_simple_onet:Outside IPv4 network address. # firewall_simple_iif_ipv6:Inside IPv6 network interface. # firewall_simple_inet_ipv6: Inside IPv6 network prefix. # firewall_simple_oif_ipv6:Outside IPv6 network interface. # firewall_simple_onet_ipv6: Outside IPv6 network prefix. The MAJOR difference being that CLIENT is just an end node on a network, where as SIMPLE is actually a forwarding router setup with 2 interfaces. -- Rod Grimes rgri...@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: Look for an ipfw example using NPTv6
> Oh, the problem is simply that my ISP assigns me a ::/64 but there is no > guarantee that it's mine for the duration. > > I'm in the process of securing my own IPv6 block, but was hoping for an > interim solution. > > One that occurred to me is to use a public ::/56 that's allocated (but > unused) to me in an AWS VPC. Route advertisements from them would make > them unusable directly, but then NPTv6 would work. > > Open to any suggestions ;-) Go to the he.net tunnel broker (https://tunnelbroker.net/), get a tunnel, get a /48, put that behind your NPTv6. Be Happy. :-) > ? M > > On Thu, Jun 20, 2019 at 2:57 AM Jan Bramkamp wrote: > > > On 18.06.19 22:00, Michael Sierchio wrote: > > > I'm looking for a simple firewall example using nptv6 to translate > > > link-local addresses to match the prefix assigned by my ISP. I'll be > > using > > > stateful rules and allowing only outbound traffic. > > > > > > If you have a snippet, I'l be grateful. Thanks. > > > > > This sounds like you're trying to force IPv6 to behave like IPv4 with > > longer addresses and just replaced RFC1918 addresses with link local > > addresses. This isn't going to work because the differences are larger > > than just the addresses length. Link local addresses are just what the > > name says: they are local to the link. A link local address isn't even > > unique within a host e.g. you can have fe80::1234%em0 and fe80::1234%em1 > > on the same host. > > > > In theory you can get very close to NAT between global unicast addresses > > and private addresses by configuring NPTv6 between global unicast > > addresses and unique local addresses, but that would be a terrible > > choice. One of the great advantages of IPv6 it removes the address > > scarcity that forced NAT upon us. Each IPv6 device have as many global > > IPv6 unicast addresses as required. > > > > Would you feel comfortable to describe the constrains shaping your > > design to us? > > > > ___ > > 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," Brahm? said, "even after ten thousand explanations, a fool is no > wiser, but an intelligent person requires only two thousand five hundred." > > - The Mah?bh?rata > ___ > 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" > > -- Rod Grimes rgri...@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: amazonaws
> Hi! > > Is it possible to bl;ock compute.amazonasws.com with ipfw firewall. I > have a table with many amazonasws IPs but every time when I start > Firefox it shows the new one (I am checkong with tcpdump). Since it is almost impossible to keep up with the IP's that this may result in perhaps changing /etc/host.conf to be hosts dns and then: echo "127.0.0.1 compute.amazonasws.com" >>/etc/hosts would achive your disire to not be accessing those systems. This method can be implemented on almost any OS, including windows. Regards, -- Rod Grimes rgri...@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: amazonaws
> > On Tue, Aug 6, 2019 at 6:23 PM Rodney W. Grimes < > > freebsd-...@gndrsh.dnsmgr.net> wrote: > > > > > > Hi! > > > > > > > > Is it possible to bl;ock compute.amazonasws.com with ipfw firewall. I > > > > have a table with many amazonasws IPs but every time when I start > > > > Firefox it shows the new one (I am checkong with tcpdump). > > > > > > Since it is almost impossible to keep up with the IP's > > > > > > > This is not even remotely true. > > > > https://ip-ranges.amazonaws.com/ip-ranges.json ^^^ > > > > is kept up-to-date, and you can subscribe to an SNS topic to be notified of > > changes: > > That is ALL amazon address space, not the specific "compute.amazonasws.com" > address only. I do not see how you can derive the valid values of this > from the presented URL. Notice the small descrete non equal domain name? This is not even amazon aws at all, only made to look like it: Domain Name: amazonasws.com Registry Domain ID: 1907818131_DOMAIN_COM-VRSN Registrar WHOIS Server: whois.psi-usa.info Registrar URL: https://www.psi-usa.info Updated Date: 2019-07-01T05:31:07Z Creation Date: 2015-03-06T19:40:26Z Registrar Registration Expiration Date: 2020-03-06T19:40:26Z Registrar: PSI-USA, Inc. dba Domain Robot Registrar IANA ID: 151 Registrar Abuse Contact Email: domain-ab...@psi-usa.info Registrar Abuse Contact Phone: +49.94159559482 Domain Status: clientTransferProhibited https://www.icann.org/epp#clientTransferProhibited Registry Registrant ID: REDACTED FOR PRIVACY Registrant Name: REDACTED FOR PRIVACY Registrant Organization: HUSH IP LLC Registrant Street: REDACTED FOR PRIVACY Registrant City: REDACTED FOR PRIVACY Registrant State/Province: AZ Registrant Postal Code: REDACTED FOR PRIVACY Registrant Country: US Registrant Phone: REDACTED FOR PRIVACY Registrant Phone Ext: REDACTED FOR PRIVACY Registrant Fax: REDACTED FOR PRIVACY Registrant Fax Ext: REDACTED FOR PRIVACY Registrant Email: https://contact.domain-robot.org/amazonasws.com Registry Admin ID: REDACTED FOR PRIVACY Admin Name: REDACTED FOR PRIVACY Admin Organization: REDACTED FOR PRIVACY Admin Street: REDACTED FOR PRIVACY Admin City: REDACTED FOR PRIVACY Admin State/Province: REDACTED FOR PRIVACY Admin Postal Code: REDACTED FOR PRIVACY Admin Country: REDACTED FOR PRIVACY Admin Phone: REDACTED FOR PRIVACY Admin Phone Ext: REDACTED FOR PRIVACY Admin Fax: REDACTED FOR PRIVACY Admin Fax Ext: REDACTED FOR PRIVACY Admin Email: https://contact.domain-robot.org/amazonasws.com Registry Tech ID: REDACTED FOR PRIVACY Tech Name: REDACTED FOR PRIVACY Tech Organization: REDACTED FOR PRIVACY Tech Street: REDACTED FOR PRIVACY Tech City: REDACTED FOR PRIVACY Tech State/Province: REDACTED FOR PRIVACY Tech Postal Code: REDACTED FOR PRIVACY Tech Country: REDACTED FOR PRIVACY Tech Phone: REDACTED FOR PRIVACY Tech Phone Ext: REDACTED FOR PRIVACY Tech Fax: REDACTED FOR PRIVACY Tech Fax Ext: REDACTED FOR PRIVACY Tech Email: https://contact.domain-robot.org/amazonasws.com Name Server: ns1.parkingcrew.net Name Server: ns2.parkingcrew.net DNSSEC: unsigned URL of the ICANN WHOIS Data Problem Reporting System: https://wdprs.internic.net/ >>> Last update of WHOIS database: 2019-08-07T05:03:35Z <<< > > > arn:aws:sns:us-east-1:806199016981:AmazonIpSpaceChanged > > > > > > > > You could put the entire contents, or a portion of it, in an ipfw table and > > swap tables atomically upon change. > > Which would block ALL amazon hosted services, not just the specific > that is "compute". > > # drill compute.amazonasws.com > ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 35891 > ;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1 > ;; QUESTION SECTION: > ;; compute.amazonasws.com. IN A > > ;; ANSWER SECTION: > compute.amazonasws.com. 600 IN A 185.53.179.8 > > ;; AUTHORITY SECTION: > amazonasws.com. 172799 IN NS ns2.parkingcrew.net. > amazonasws.com. 172799 IN NS ns1.parkingcrew.net. > > ;; ADDITIONAL SECTION: > ns1.parkingcrew.net.300 IN A 13.248.158.159 > > > Which I believe to be an advertising sprinkler used by all > sorts of stuff to spam your browser with a random ad page. Defanitly confirmed, each open of the url: http://compute.amazonasws.com takes you to a new spam ad > > > > -- > > > > "Well," Brahm? said, "even after ten thousand explanations, a fool is no > > wiser, but an intelligent person requires only two thousand five hundred." > > > > - The Mah?bh?rata > > _
Re: amazonaws
> On Tue, Aug 6, 2019 at 6:23 PM Rodney W. Grimes < > freebsd-...@gndrsh.dnsmgr.net> wrote: > > > > Hi! > > > > > > Is it possible to bl;ock compute.amazonasws.com with ipfw firewall. I > > > have a table with many amazonasws IPs but every time when I start > > > Firefox it shows the new one (I am checkong with tcpdump). > > > > Since it is almost impossible to keep up with the IP's > > > > This is not even remotely true. > > https://ip-ranges.amazonaws.com/ip-ranges.json > > is kept up-to-date, and you can subscribe to an SNS topic to be notified of > changes: That is ALL amazon address space, not the specific "compute.amazonasws.com" address only. I do not see how you can derive the valid values of this from the presented URL. > arn:aws:sns:us-east-1:806199016981:AmazonIpSpaceChanged > > > > You could put the entire contents, or a portion of it, in an ipfw table and > swap tables atomically upon change. Which would block ALL amazon hosted services, not just the specific that is "compute". # drill compute.amazonasws.com ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 35891 ;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1 ;; QUESTION SECTION: ;; compute.amazonasws.com. IN A ;; ANSWER SECTION: compute.amazonasws.com. 600 IN A 185.53.179.8 ;; AUTHORITY SECTION: amazonasws.com. 172799 IN NS ns2.parkingcrew.net. amazonasws.com. 172799 IN NS ns1.parkingcrew.net. ;; ADDITIONAL SECTION: ns1.parkingcrew.net.300 IN A 13.248.158.159 Which I believe to be an advertising sprinkler used by all sorts of stuff to spam your browser with a random ad page. > -- > > "Well," Brahm? said, "even after ten thousand explanations, a fool is no > wiser, but an intelligent person requires only two thousand five hundred." > > - The Mah?bh?rata > ___ > 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" > > -- Rod Grimes rgri...@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: amazonaws
> On Tue, 6 Aug 2019 18:42:29 -0700 > Michael Sierchio wrote: > > > On Tue, Aug 6, 2019 at 6:23 PM Rodney W. Grimes < > > freebsd-...@gndrsh.dnsmgr.net> wrote: > > > > > > Hi! > > > > > > > > Is it possible to bl;ock compute.amazonasws.com with ipfw > > > > firewall. I have a table with many amazonasws IPs but every time > > > > when I start Firefox it shows the new one (I am checkong with > > > > tcpdump). > > > > > > Since it is almost impossible to keep up with the IP's > > > > > > > This is not even remotely true. > > > > https://ip-ranges.amazonaws.com/ip-ranges.json > > > > is kept up-to-date, and you can subscribe to an SNS topic to be > > notified of changes: > > > > arn:aws:sns:us-east-1:806199016981:AmazonIpSpaceChanged > > > > > > > > You could put the entire contents, or a portion of it, in an ipfw > > table and swap tables atomically upon change. > > > > I did try but there are not just compute.amazonasws.com as Rodney W. > Grimesand wrote and with all blockings come more problems. This is a spammer, scrapper, abuser, probably the only effective means of controlling some of it is use of RBL or other blacklists. Another would be amazon security should be prodded into taking trademark issue, but the most that could happen there is the domain name revoked, and the spammer just goes on to another high profile domain name like microsaft.com # host microsaft.com microsaft.com has address 93.191.156.32 microsaft.com mail is handled by 10 mx.unoeuro.com. Welcome to the free world of anyone can be an abuser :-( -- Rod Grimes rgri...@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: igmp query v3
> Hi! > > My system is FreeBSD 12.0-RELEASE-p10 (amd64) and I start learning ipfw > firewall. > I have a line: > cmd 01090 deny log all from any to 224.0.0.0/4 in via $pif ^^^ all translates to ipv4 or ipv6 >From /etc/protocols ip is protocol 0, ipv6 is protocol 41 igmp is protocol 2 Your rule needs to be cmd 01090 deny log igmp from any to 224.0.0.0/4 in via $pif > but I never seen anything about blocking igmp. > Mine pf firewall settings block all the time and I get: > > listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size > 262144 bytes > 2019-10-05 06:47:08.677668 rule 12/0(match): block in on bge0: > 192.168.1.1 > 224.0.0.1: igmp query v3 [max resp time 1.0s] > > Why ipfw doesn't block anything, please? What I doing wrong? > > Thank you. > > > -- > ?Hungry man, reach for the book: it is a weapon.? > > ? Bertolt Brecht > ___ > 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" > > -- Rod Grimes rgri...@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: Odd ipfw behavior with UDP query on the same host
> Hey ipfw folks ? Im skipping questions@ and asking this directly here, > > FreeBSD 12.4 (amd64) > > Assume a partial firewall ruleset like this: > > 00300 0 0 allow ip from any to any via lo0 > 00400 0 0 allow ip from any to any via lo1 > 00500 0 0 deny ip from any to 127.0.0.0/8 in > 00600 0 0 deny ip from any to ::/64 in > 01600 1 174 allow ip from any to me 53 in // DNS queries 1650 x x allow ip from me 53 to me in // DNS local answers > 01700 1 293 allow ip from me 53 to any out // DNS responses > 03000 0 0 reset log ip from any to any > 65535 0 0 allow ip from any to any > > For some reason, with the above, I?m able to query a DNS server living on my > own (public) ipv6 interface, i,e: > > dig @2001:b00b:6b:2::53 version.bind CH TXT: > ;communications error to 2001:b00b:6b:2::53#53: timed out > > This is not a bind config problem. Bind answers from outside and everywhere > else but itself. We can argue about that, but given the below log entries your not using ::1 for local ipv6 dns, but your using your interface ipv6 address. What is in your /etc/resolv.conf file? > > == > > If I change rule 1600 to simply be "allow ip from any to me 53? it works. > > If I do ipfw disable firewall it works. > > Localhost always works. As long as ipv4 is done first, if you flip the order of preference for ipv4 and ipv6 it probably stops working. > > Using the ipv4 address works. > > == > > It?s only when using an ipv6 interface ip on the same box that this breaks. > TCP also works, this only seems to be a UDP issue. How are you testing the TCP? > My best guess is something about the ?inbound/outbound? determination logic > is weird in ipv6. > > My log rule shows: > Jun 3 23:44:35 box kernel: ipfw: 3000 Deny UDP [2001:b00b:6b:2::53]:53 > [2001:b00b:6b:2::53]:26588 in via em0 > Jun 3 23:44:40 box kernel: ipfw: 3000 Deny UDP [2001:b00b:6b:2::53]:53 > [2001:b00b:6b:2::53]:32389 in via em0 The clue as to what is wrong is right here --^^ The src and dst IP address of those packets is the same, and I am going to assume that it is the interface address of em0. Nothing in your rule allows these packets through, which are local answers from DNS to local queries made to that interface IP address. > > ipv4 doesn?t show this problem. Subnet masks and the like are correct. ipv4 has a special loopback route on lo0 that does not exist for ipv6. Look at: netstat -rn > Any ideas? > > -Dan -- Rod Grimes rgri...@freebsd.org
Re: Odd ipfw behavior with UDP query on the same host
> > > > On Jun 4, 2023, at 12:07 PM, Rodney W. Grimes > > wrote: > > > >> Hey ipfw folks ? Im skipping questions@ and asking this directly here, > >> > >> FreeBSD 12.4 (amd64) > >> > >> Assume a partial firewall ruleset like this: > >> > >> 00300 0 0 allow ip from any to any via lo0 > >> 00400 0 0 allow ip from any to any via lo1 > >> 00500 0 0 deny ip from any to 127.0.0.0/8 in > >> 00600 0 0 deny ip from any to ::/64 in > >> 01600 1 174 allow ip from any to me 53 in // DNS queries > > > > 1650 x x allow ip from me 53 to me in // DNS local answers I strongly suggest this is a correct fix, as it does not depend on any routing entries. > >> 01700 1 293 allow ip from me 53 to any out // DNS responses > >> 03000 0 0 reset log ip from any to any > >> 65535 0 0 allow ip from any to any > >> > >> For some reason, with the above, I?m able to query a DNS server living on > >> my own (public) ipv6 interface, i,e: > >> > >> dig @2001:b00b:6b:2::53 version.bind CH TXT: > >> ;communications error to 2001:b00b:6b:2::53#53: timed out > >> > >> This is not a bind config problem. Bind answers from outside and > >> everywhere else but itself. > > > > We can argue about that, but given the below log entries your not using ::1 > > for local ipv6 dns, but your using your interface ipv6 address. > > What is in your /etc/resolv.conf file? > > That doesn?t matter, this isn?t the box?s local resolver, it?s an > authoritative server that we?re sending test queries against to make sure > it?s answering. They work from off-box but not on-box. Ok, that simplifies things. > > I?m posting from my personal account, but you could say my day job is very > familiar with dig and bind. :) > > >> == > >> > >> If I change rule 1600 to simply be "allow ip from any to me 53? it works. > >> > >> If I do ipfw disable firewall it works. > >> > >> Localhost always works. > > As long as ipv4 is done first, if you flip the order of preference for > > ipv4 and ipv6 it probably stops working. > > It does not. See below, I test all iterations of tcp/udp ipv4/ipv6 box > ip/localhost ? the only failing one is interface-ip, ipv6, udp Since your using dig and expicityly giving an IP address it elminates this source of potential problems. > > > >> > >> Using the ipv4 address works. > >> > >> == > >> > >> It?s only when using an ipv6 interface ip on the same box that this > >> breaks. TCP also works, this only seems to be a UDP issue. > > > > How are you testing the TCP? > > Same as we?re testing the UDP. With dig. > > dig +short @boxname version.bind CH TXT > ;; communications error to 2001:b00b:1:f::88#53: timed out > ;; communications error to 2001:b00b:1:f::88#53: timed out > ;; communications error to 2001:b00b:1:f::88#53: timed out > "9.16.40" > $ dig +short @localhost version.bind CH TXT > "9.16.40" > $ dig +short +tcp @localhost version.bind CH TXT > "9.16.40" > $ dig +short +tcp @boxname version.bind CH TXT > "9.16.40" > $ dig -4 +short +tcp @boxname version.bind CH TXT > "9.16.40" > $ dig -4 +short @boxname version.bind CH TXT > "9.16.40" > $ dig -4 +short @localhost version.bind CH TXT > "9.16.40" > $ dig -4 +short +tcp @localhost version.bind CH TXT > "9.16.40" Has bind opened a socket on 2001:b00b:1:f::88#53? netstat -an > > > > >> My best guess is something about the ?inbound/outbound? determination > >> logic is weird in ipv6. > >> > >> My log rule shows: > >> Jun 3 23:44:35 box kernel: ipfw: 3000 Deny UDP [2001:b00b:6b:2::53]:53 > >> [2001:b00b:6b:2::53]:26588 in via em0 > >> Jun 3 23:44:40 box kernel: ipfw: 3000 Deny UDP [2001:b00b:6b:2::53]:53 > >> [2001:b00b:6b:2::53]:32389 in via em0 > > > > The clue as to what is wrong is right here > > --^^ > > > > The src and dst IP address of those packets is the same, and I am going to > > assume that it is the > > interface address of em0. Nothing in your rule allows these packets > > through, which are local > > answers from DNS to local queries made to that interface IP address. > > Given the routing table below (which is for a different box with a similar > route), why was this not sent via lo0? That is
Re: Odd ipfw behavior with UDP query on the same host
> > > > > > > On Jun 4, 2023, at 12:07 PM, Rodney W. Grimes > > > wrote: > > > > > >> Hey ipfw folks ? Im skipping questions@ and asking this directly here, > > >> > > >> FreeBSD 12.4 (amd64) > > >> > > >> Assume a partial firewall ruleset like this: > > >> > > >> 00300 0 0 allow ip from any to any via lo0 > > >> 00400 0 0 allow ip from any to any via lo1 > > >> 00500 0 0 deny ip from any to 127.0.0.0/8 in > > >> 00600 0 0 deny ip from any to ::/64 in > > >> 01600 1 174 allow ip from any to me 53 in // DNS queries > > > > > > 1650 x x allow ip from me 53 to me in // DNS local answers > > I strongly suggest this is a correct fix, as it does not > depend on any routing entries. On second thought, thats wrong, that opens a spoof ability by allowing an external packet to enter via em0 that is from our address. > > > >> 01700 1 293 allow ip from me 53 to any out // DNS responses > > >> 03000 0 0 reset log ip from any to any > > >> 65535 0 0 allow ip from any to any > > >> > > >> For some reason, with the above, I?m able to query a DNS server living > > >> on my own (public) ipv6 interface, i,e: > > >> > > >> dig @2001:b00b:6b:2::53 version.bind CH TXT: > > >> ;communications error to 2001:b00b:6b:2::53#53: timed out > > >> > > >> This is not a bind config problem. Bind answers from outside and > > >> everywhere else but itself. > > > > > > We can argue about that, but given the below log entries your not using > > > ::1 > > > for local ipv6 dns, but your using your interface ipv6 address. > > > What is in your /etc/resolv.conf file? > > > > That doesn?t matter, this isn?t the box?s local resolver, it?s an > > authoritative server that we?re sending test queries against to make sure > > it?s answering. They work from off-box but not on-box. > > Ok, that simplifies things. > > > > > I?m posting from my personal account, but you could say my day job is very > > familiar with dig and bind. :) > > > > >> == > > >> > > >> If I change rule 1600 to simply be "allow ip from any to me 53? it > > >> works. > > >> > > >> If I do ipfw disable firewall it works. > > >> > > >> Localhost always works. > > > As long as ipv4 is done first, if you flip the order of preference for > > > ipv4 and ipv6 it probably stops working. > > > > It does not. See below, I test all iterations of tcp/udp ipv4/ipv6 box > > ip/localhost ? the only failing one is interface-ip, ipv6, udp > > Since your using dig and expicityly giving an IP address it elminates this > source of potential problems. > > > > > > >> > > >> Using the ipv4 address works. > > >> > > >> == > > >> > > >> It?s only when using an ipv6 interface ip on the same box that this > > >> breaks. TCP also works, this only seems to be a UDP issue. > > > > > > How are you testing the TCP? > > > > Same as we?re testing the UDP. With dig. > > > > dig +short @boxname version.bind CH TXT > > ;; communications error to 2001:b00b:1:f::88#53: timed out > > ;; communications error to 2001:b00b:1:f::88#53: timed out > > ;; communications error to 2001:b00b:1:f::88#53: timed out Can we get verbose ipfw logging during this set of transactions, both allow and deny. > > "9.16.40" > > $ dig +short @localhost version.bind CH TXT > > "9.16.40" > > $ dig +short +tcp @localhost version.bind CH TXT > > "9.16.40" > > $ dig +short +tcp @boxname version.bind CH TXT > > "9.16.40" > > $ dig -4 +short +tcp @boxname version.bind CH TXT > > "9.16.40" > > $ dig -4 +short @boxname version.bind CH TXT > > "9.16.40" > > $ dig -4 +short @localhost version.bind CH TXT > > "9.16.40" > > $ dig -4 +short +tcp @localhost version.bind CH TXT > > "9.16.40" > > Has bind opened a socket on 2001:b00b:1:f::88#53? > netstat -an > > > > > > > > >> My best guess is something about the ?inbound/outbound? determination > > >> logic is weird in ipv6. > > >> > > >> My log rule shows: > > >> Jun 3 23:44:35 box kernel: ipfw: 3000 Deny UDP [2001:b00b:6b:2::53]:53 >
