Sorry for the long post, but I wanted to get as many details in it as possible.
I'm running a bit of an "unconventional" setup, which is basically a Apple Time Capsule (4th gen with build-in Airport Extreme functionality, including WiFi-accesspoint, "router" and others), with build-in "DHCP and NAT*" service activated (part of the Airport Extreme-functionality). For curiosity purposes I have set up a NET4801 with three NICs (sis0 - sis2) as a filtering bridge, running FreeBSD 10.0 GENERIC, on the WAN-side of the Time Capsule (TC). This has generated two questions.
Basically the layout is such (see also attached drawing), that my internet provider's (Danish company, that has specialised in apartments) connection is a ethernet plug in our wall (they then have a wiring closet in our building, where all apartments are connected to their switch and fiber optic terminator). They provide a internal IP-address, which is in the 10.84.168/24-range. sis0 on the Soekris is connected to the Ethernet plug in the wall. sis1 is connected to the WAN-port on the TC. sis2 is connected to a LAN-port on the TC and has a static address on my LAN side (the address is 10.0.0.2, the LAN is 10.0.0/24, the TC is static on 10.0.0.1 and it's DHCP-service hands out 10.0.0.10-10.0.0.99).
The bridge (bridge0) is set up more or less as the example in the handbook. It's all in the readout from rc.conf:
The output of ifconfig is:
My ipfw rules are rather simplistic (I'm still in the work-up phase of this):
And it's all working. Except that I get a lot of the following in /var/log/security:
If I read and understands the ipfw(8) and the ipfw-handbook-page correctly, rule number 200 catches all those packets that didn't match the check-state rule (100), but still have SYN+ACK bits set.
My first question is, if my understanding of ipfw + check-state + established is correct?
The counter was reset a few minutes prior, and as far as I know, the check-state rule (100), shouldn't count up anyways. What bugs me, is that these logged entries in /var/log/security seems to be almost exclusively to the 17/8-network-range (which is registered to Apple Inc.). The three 10.0.0.18 <-> 10.0.0.2 is me running three SSH-sessions to the Soekris.
My second question - which I guess could just as well be asked in the Apple Wireless forum, except that (judged by what-ever answers I've been able to find there so far) I'll most likely get an answer along the lines of "you are just interfering with the normal operation of your system and wasting your time with useless information", so I'm guessing that the chance of a qualified answer is better here - is, if anybody has ever done some (ipfw-) filtering on an Time Capsule / Airport Extreme (or perhaps other Apple-product) and if so, if they have experienced something similar?
At the time of this logging, only the TC, the Soekris and a MacMini on the LAN-side was turned on to minimize traffic (normally there is also a couple of Apple TVs, an iPad, a couple of Windows laptops and a MacBook on the LAN-side, depending on the time of day).
* = It's not really NAT but PAT/IP-masquerading.
I'm running a bit of an "unconventional" setup, which is basically a Apple Time Capsule (4th gen with build-in Airport Extreme functionality, including WiFi-accesspoint, "router" and others), with build-in "DHCP and NAT*" service activated (part of the Airport Extreme-functionality). For curiosity purposes I have set up a NET4801 with three NICs (sis0 - sis2) as a filtering bridge, running FreeBSD 10.0 GENERIC, on the WAN-side of the Time Capsule (TC). This has generated two questions.
Basically the layout is such (see also attached drawing), that my internet provider's (Danish company, that has specialised in apartments) connection is a ethernet plug in our wall (they then have a wiring closet in our building, where all apartments are connected to their switch and fiber optic terminator). They provide a internal IP-address, which is in the 10.84.168/24-range. sis0 on the Soekris is connected to the Ethernet plug in the wall. sis1 is connected to the WAN-port on the TC. sis2 is connected to a LAN-port on the TC and has a static address on my LAN side (the address is 10.0.0.2, the LAN is 10.0.0/24, the TC is static on 10.0.0.1 and it's DHCP-service hands out 10.0.0.10-10.0.0.99).
The bridge (bridge0) is set up more or less as the example in the handbook. It's all in the readout from rc.conf:
Code:
root@glove:~ # cat /etc/rc.conf
hostname="glove"
keymap="danish.iso.kbd"
cloned_interfaces="bridge0"
ifconfig_bridge0="addm sis0 addm sis1 up"
ifconfig_sis0="up"
ifconfig_sis1="up"
ifconfig_sis2="inet 10.0.0.2 netmask 255.255.255.0"
defaultrouter="10.0.0.1"
sshd_enable="YES"
firewall_enable="YES"
firewall_logging="YES"
firewall_type="open"
firewall_script="/etc/ipfw.rules"
# Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable
dumpdev="AUTO"
root@glove:~ #The output of ifconfig is:
Code:
sis0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=83808<VLAN_MTU,WOL_UCAST,WOL_MCAST,WOL_MAGIC,LINKSTATE>
ether 00:00:24:c6:1a:74
inet6 fe80::200:24ff:fec6:1a74%sis0 prefixlen 64 scopeid 0x1
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
sis1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=83808<VLAN_MTU,WOL_UCAST,WOL_MCAST,WOL_MAGIC,LINKSTATE>
ether 00:00:24:c6:1a:75
inet6 fe80::200:24ff:fec6:1a75%sis1 prefixlen 64 scopeid 0x2
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
sis2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=83808<VLAN_MTU,WOL_UCAST,WOL_MCAST,WOL_MAGIC,LINKSTATE>
ether 00:00:24:c6:1a:76
inet 10.0.0.2 netmask 0xffffff00 broadcast 10.0.0.255
inet6 fe80::200:24ff:fec6:1a76%sis2 prefixlen 64 scopeid 0x3
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
inet 127.0.0.1 netmask 0xff000000
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 02:22:09:81:c8:00
nd6 options=9<PERFORMNUD,IFDISABLED>
id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
member: sis1 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 2 priority 128 path cost 200000
member: sis0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 1 priority 128 path cost 200000My ipfw rules are rather simplistic (I'm still in the work-up phase of this):
Code:
root@glove:~ # ipfw list
00100 check-state
00200 deny log tcp from any to any established
00300 allow tcp from 10.84.168.95 to any setup keep-state
01000 allow ip from 10.0.0.0/24 to me in via sis2 setup keep-state
07000 allow log tcp from any to any setup
07001 allow tcp from any to any keep-state
08000 deny log ip from any to any frag
10000 allow ip from any to any
65000 deny log ip from any to any
65535 deny ip from any to any
root@glove:~ #And it's all working. Except that I get a lot of the following in /var/log/security:
Code:
May 5 18:43:11 glove kernel: ipfw: 200 Deny TCP 17.172.232.119:5223 10.84.168.95:45982 in via sis0
May 5 18:43:11 glove kernel: ipfw: 200 Deny TCP 17.172.232.119:5223 10.84.168.95:45982 in via sis0
May 5 18:43:12 glove kernel: ipfw: 200 Deny TCP 10.84.168.95:45982 17.172.232.119:5223 in via sis1
May 5 18:43:12 glove kernel: ipfw: 200 Deny TCP 17.172.232.119:5223 10.84.168.95:45982 in via sis0
May 5 18:43:16 glove kernel: ipfw: 200 Deny TCP 17.172.232.119:5223 10.84.168.95:45982 in via sis0
May 5 18:43:21 glove kernel: ipfw: 200 Deny TCP 10.84.168.95:45982 17.172.232.119:5223 in via sis1
May 5 18:43:22 glove kernel: ipfw: 200 Deny TCP 17.172.232.119:5223 10.84.168.95:45982 in via sis0
May 5 18:43:30 glove kernel: ipfw: 200 Deny TCP 10.84.168.95:45982 17.172.232.119:5223 in via sis1
May 5 18:43:35 glove kernel: ipfw: 200 Deny TCP 17.172.232.119:5223 10.84.168.95:45982 in via sis0
May 5 18:43:48 glove kernel: ipfw: 200 Deny TCP 10.84.168.95:45982 17.172.232.119:5223 in via sis1If I read and understands the ipfw(8) and the ipfw-handbook-page correctly, rule number 200 catches all those packets that didn't match the check-state rule (100), but still have SYN+ACK bits set.
My first question is, if my understanding of ipfw + check-state + established is correct?
ipfw -ade list run at the same time gives the following:
Code:
00100 0 0 check-state
00200 76 5412 deny log tcp from any to any established
00300 249828 254043592 allow tcp from 10.84.168.95 to any setup keep-state
01000 9483 3851359 allow ip from 10.0.0.0/24 to me in via sis2 setup keep-state
07000 14 840 allow log tcp from any to any setup
07001 0 0 allow tcp from any to any keep-state
08000 0 0 deny log ip from any to any frag
10000 1050 122252 allow ip from any to any
65000 0 0 deny log ip from any to any
65535 0 0 deny ip from any to any
## Dynamic rules (19):
00300 6479 370824 (273s) STATE tcp 10.84.168.95 46408 <-> 74.125.136.125 5222
00300 107 13976 (220s) STATE tcp 10.84.168.95 40569 <-> 74.125.136.147 443
00300 75 27432 (117s) STATE tcp 10.84.168.95 43160 <-> 74.125.136.104 443
01000 679 72780 (298s) STATE tcp 10.0.0.18 49176 <-> 10.0.0.2 22
00300 83 27176 (290s) STATE tcp 10.84.168.95 33180 <-> 74.125.136.95 443
01000 462 51611 (300s) STATE tcp 10.0.0.18 49192 <-> 10.0.0.2 22
00300 107 22784 (231s) STATE tcp 10.84.168.95 44681 <-> 17.149.36.81 443
01000 8676 3760932 (297s) STATE tcp 10.0.0.18 49209 <-> 10.0.0.2 22
00300 27 2736 (96s) STATE tcp 10.84.168.95 37422 <-> 74.125.136.101 80
00300 83 27736 (186s) STATE tcp 10.84.168.95 42139 <-> 199.16.156.43 443
00300 39 5636 (0s) STATE tcp 10.84.168.95 39648 <-> 74.125.136.157 80
00300 295 59920 (269s) STATE tcp 10.84.168.95 48965 <-> 108.160.167.51 80
00300 79 12916 (289s) STATE tcp 10.84.168.95 34427 <-> 54.217.232.244 80
00300 67 24780 (300s) STATE tcp 10.84.168.95 49086 <-> 178.236.7.220 443
00300 71 27004 (299s) STATE tcp 10.84.168.95 45891 <-> 199.16.156.43 443
00300 115 33388 (273s) STATE tcp 10.84.168.95 32819 <-> 74.125.136.101 443
00300 27 2736 (270s) STATE tcp 10.84.168.95 35285 <-> 74.125.136.101 80
00300 135 30148 (284s) STATE tcp 10.84.168.95 40056 <-> 74.125.136.188 5228
00300 87 23468 (187s) STATE tcp 10.84.168.95 46210 <-> 192.241.190.153 443The counter was reset a few minutes prior, and as far as I know, the check-state rule (100), shouldn't count up anyways. What bugs me, is that these logged entries in /var/log/security seems to be almost exclusively to the 17/8-network-range (which is registered to Apple Inc.). The three 10.0.0.18 <-> 10.0.0.2 is me running three SSH-sessions to the Soekris.
My second question - which I guess could just as well be asked in the Apple Wireless forum, except that (judged by what-ever answers I've been able to find there so far) I'll most likely get an answer along the lines of "you are just interfering with the normal operation of your system and wasting your time with useless information", so I'm guessing that the chance of a qualified answer is better here - is, if anybody has ever done some (ipfw-) filtering on an Time Capsule / Airport Extreme (or perhaps other Apple-product) and if so, if they have experienced something similar?
At the time of this logging, only the TC, the Soekris and a MacMini on the LAN-side was turned on to minimize traffic (normally there is also a couple of Apple TVs, an iPad, a couple of Windows laptops and a MacBook on the LAN-side, depending on the time of day).
* = It's not really NAT but PAT/IP-masquerading.
