Date: Mon, 15 Apr 2013 03:26:50 +1000 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Spil Oss <spil.oss@gmail.com> Cc: freebsd-ipfw@freebsd.org Subject: Re: Problems with ipfw/natd and axe(4) Message-ID: <20130415015850.Y56386@sola.nimnet.asn.au> In-Reply-To: <CAEJyAvOZ6fW0i3yT_D4fH1huje-qsJwA7GGeXqAO1PKzge-YNw@mail.gmail.com> References: <CAEJyAvOZ6fW0i3yT_D4fH1huje-qsJwA7GGeXqAO1PKzge-YNw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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?20130415015850.Y56386>