Date: Sun, 14 Apr 2013 21:02:05 +0200 From: Spil Oss <spil.oss@gmail.com> To: Ian Smith <smithi@nimnet.asn.au> Cc: freebsd-ipfw@freebsd.org Subject: Re: Problems with ipfw/natd and axe(4) Message-ID: <CAEJyAvPFuuKa9EemroR_E_-M5ure2AF-97uDj9C_jP%2B7=X=UAQ@mail.gmail.com> In-Reply-To: <20130415015850.Y56386@sola.nimnet.asn.au> References: <CAEJyAvOZ6fW0i3yT_D4fH1huje-qsJwA7GGeXqAO1PKzge-YNw@mail.gmail.com> <20130415015850.Y56386@sola.nimnet.asn.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Ian,
Testing the machine I connect it to my LAN which runs on 172.17.2.1/24 so I
had to delete these 2 anti-spoofing rules whilst setting up
4200 is me forgetting to set the rulenumber 10 to at least allow me to get
to the machine... And indeed not very safe :D Not an issue as long as the
machine is in testing on my LAN
Added some services indeed to the default set but haven't gotten further
than testing ssh.
I'd love the patches to test in-kernel nat :D
I had plans of switching to ipfw_nat but haven't yet wanting to stay close
to the default ruleset, learn and then improve.
Your comments in my ruleset are a nice narrative of why and how these rules
work! Thanks!
I'll create some tcpdumps including icmp, in various test-cases. ue0 <->
re0 reversed as well to show differences.
I have a thread about the axe NIC as well not wanting to work with
checksumming disabled, will follow up there as well!
Switching re0 and ue0 is an option for testing, but running my LAN on Fast
Ethernet wasn't in my plans :D I'm still looking for some other USB NIC as
this box but find ASIX parts only. This machine has no other interfaces I
can connect an additional NIC to.
Thanks!
Spil.
On Sun, Apr 14, 2013 at 7:26 PM, Ian Smith <smithi@nimnet.asn.au> wrote:
> On Sat, 13 Apr 2013 15:34:39 +0200, Spil Oss wrote:
> > Hi All,
> >
> > I can't use ipfw with natd with my ASIX AX88772B USB NIC
> >
> > ipfw ruleset (slightly modified /etc/rc.firewall simple ruleset)
>
> I see you omitted the 2 anti-spoofing rules for 172.16.0.0/12 either
> side of the divert rule, as you had to, seeing your outside interface
> (so, gateway) is on 172.17.2.111(/24?). I didn't see any other changes
> to 'simple' apart from rules 10 and the equally weird rule 4200, plus
> your extra tcp services below. Is that right?
>
> > 00010 allow ip from any to me dst-port 22 recv ue0
> > 00010 allow tcp from me 22 to any xmit ue0
>
> That these rules make the particular client connection from the gateway
> work seemed pretty confusing, as you properly allow ssh connections in
> below, and allow all established tcp, however ..
>
> 'allow ip' aka 'allow all' doesn't usually take a port number, which
> applies only to tcp and udp. I'm surprised this rule isn't rejected,
> unless perhaps the proto is now also tested? but in any case, this rule
> should allow at least any non-tcp and non-udp IP packet through.
>
> And that means all ICMP in from the outside will be accepted, whereas a
> long-standing bug in rc.firewall 'simple' means that NO icmp, neither in
> nor out - not even on the inside network - is passed with this ruleset.
>
> Try replacing rules 10 with this section from the 'workstation' ruleset
> (though further down, probably after NAT, would be a better place):
>
> # Allow "mandatory" ICMP in.
> ${fwcmd} add pass icmp from any to any icmptype 3,4,11
> if [ $ipv6_available -eq 0 ]; then
> ${fwcmd} add pass ipv6-icmp from any to any icmp6type 3
> fi
>
> Of course Luigi is likely right about the offloaded checksumming too,
> but there's no reason not to have ICMP functioning on a router/NAT box,
> especially when it's "mandatory" for path MTU discovery. It's possible
> that there may be an MTU issue with these inbound connections here?
>
> Neither do I see any reason not to allow at least yourself and your LAN
> clients to ping. Block inbound pings from the outside if you prefer but
> allowing them outbound and ping responses in doesn't seem risky to me.
>
> > 00100 allow ip from any to any via lo0
> > 00200 deny ip from any to 127.0.0.0/8
> > 00300 deny ip from 127.0.0.0/8 to any
> > 00400 deny ip from any to ::1
> > 00500 deny ip from ::1 to any
> > 00600 allow ipv6-icmp from :: to ff02::/16
> > 00700 allow ipv6-icmp from fe80::/10 to fe80::/10
> > 00800 allow ipv6-icmp from fe80::/10 to ff02::/16
> > 00900 allow ipv6-icmp from any to any ip6 icmp6types 1
> > 01000 allow ipv6-icmp from any to any ip6 icmp6types 2,135,136
>
> > 01100 deny ip from 10.16.2.1 to any in via ue0
> > 01200 deny ip from 172.17.2.111 to any in via re0
>
> So following rc.firewall, one learns that ue0 is your outside interface
> and re0 the inside. Looking in /etc/defaults/rc.conf you'll see that
> ${inet} and ${onet} are intended to be network addresses (ip/mask) to
> protect from spoofed networks. Yours only protect against those single
> addresses, not the rest of the networks they're in - but it works now.
>
> > 01300 deny ip from any to 10.0.0.0/8 via ue0
> > 01500 deny ip from any to 192.168.0.0/16 via ue0
> > 01600 deny ip from any to 0.0.0.0/8 via ue0
> > 01700 deny ip from any to 169.254.0.0/16 via ue0
> > 01800 deny ip from any to 192.0.2.0/24 via ue0
> > 01900 deny ip from any to 224.0.0.0/4 via ue0
> > 02000 deny ip from any to 240.0.0.0/4 via ue0
> > 02100 divert 8668 ip4 from any to any via ue0
> > 02200 deny ip from 10.0.0.0/8 to any via ue0
> > 02400 deny ip from 192.168.0.0/16 to any via ue0
> > 02500 deny ip from 0.0.0.0/8 to any via ue0
> > 02600 deny ip from 169.254.0.0/16 to any via ue0
> > 02700 deny ip from 192.0.2.0/24 to any via ue0
> > 02800 deny ip from 224.0.0.0/4 to any via ue0
> > 02900 deny ip from 240.0.0.0/4 to any via ue0
>
> Longwinded these may be, and although it's a pity some couldn't convince
> some others that it was a good idea to put these into a table years ago,
> they are correct and have been done like that for ~15 years.
>
> Another more recent omission in 'simple' is allowing use of kernel
> ipfw_nat as well as or instead of natd, as you can for 'open' and
> 'client' rulesets. Yes I did submit patches :( I'm unsure whether
> ipfw_nat might or might not work better in the case Luigi outlined?
>
> > 03000 allow tcp from any to any established
> > 03100 allow ip from any to any frag
> > 03200 allow tcp from any to me dst-port 22 setup
> > 03300 allow tcp from any to me dst-port 25 setup
> > 03400 allow tcp from any to me dst-port 465 setup
> > 03500 allow tcp from any to me dst-port 587 setup
> > 03600 allow tcp from any to me dst-port 80 setup
> > 03700 allow tcp from any to me dst-port 443 setup
>
> Standard, with additional services.
>
> > 03800 deny log logamount 5 ip4 from any to any in via ue0 setup proto
> tcp
> > 03900 allow tcp from any to any setup
> > 04000 allow udp from me to any dst-port 53 keep-state
> > 04100 allow udp from me to any dst-port 123 keep-state
>
> Standard, and correctly using keep-state, for connections from this box
> and from NAT'd clients, who are after NAT also from 'me'.
>
> > 04200 allow ip from any to any dst-port 22 recv ue0
>
> As the first rule 10, that's perilously close to 'allow ip from any to
> any recv ue0' .. at least for non-tcp|udp protocols, if not for all.
>
> > 65535 deny ip from any to any
> >
> > If I remove rule 10 it will NOT work with ue0, the same ruleset without
> > rule 10 DOES work with re0 on the same machine (re0 as external and ue0
> as
> > internal NIC).
>
> This only made sense to me as an ICMP issue; I couldn't see how else
> adding those rules could resolve any rx/txcsum issues?
>
> Oh wait, yes they do bypass the divert .. well I stand by whinging about
> the lack of icmp in this ruleset, but when in doubt, listen to Luigi!
>
> > If I connect from the gateway on 172.17.2.1 to the ssh server on this
> > machine, I can see the ACK and SYN+ACK but there's no ACK from the
> client
> > to the server to establish the tcp session. Only difference I could find
> > was that the checksum was incorrect.
>
> You might need to post a tcpdump segment of the exchange, not forgetting
> to show the icmp too ..
>
> > Found an older PR kern/170081 about fxp having trouble with nat when
> > rxcsum/txcsum was enabled, that is why I started fiddling with
> > rxcsum/txcsum and found that the NIC is unusable/dead without
> rxcsum/txcsum
> > enabled so this was not an option.
>
> It would seem to be a bug in ue? or axe? if the NIC won't work without.
> Meanwhile is using re0 as the external interface an ongoing option? Of
> course, that might just move the problem to the inside interface ..
>
> > # ifconfig ue0
> > ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu
> 1500
> > options=8000b<RXCSUM,TXCSUM,VLAN_MTU,LINKSTATE>
> > ether 00:60:6e:42:5b:53
> > inet6 fe80::260:6eff:fe42:5b53%ue0 prefixlen 64 scopeid 0x7
> > inet 172.17.2.111 netmask 0xffffff00 broadcast 172.17.2.255
> > nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
> > media: Ethernet autoselect (100baseTX <full-duplex>)
> > status: active
> >
> > Any suggestions or pointers?
> >
> > Kind regards,
> >
> > Spil.
>
> cheers, Ian
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAEJyAvPFuuKa9EemroR_E_-M5ure2AF-97uDj9C_jP%2B7=X=UAQ>