[ipfw2-freebsd]filtering bridge gepruts

[axis]

Ik ben nu al een dag of twee aan het kloten met een filtering bridge, en ik krijg het gewoon niet goed aan de praat. Het bridgen wel, maar het filteren niet althans

Heb een clean install gedaan van 5.4, en die met deze guide met freebsd-update geupdate. Daarna ben ik met deze howto aan de slag gegaan:
http://www.freebsd.org/do...ring-bridges/article.html

Ik heb een doosje met 2 NIC's, xl0 en fxp0.. Aan de fxp0 kant hangen een stuk of twintig PC'tjes (allemaal in 192.168.235.0/24), en aan de xl0 kant hangt mijn laptopje (192.168.235.12). Ik wil dus het verkeer tussenbeiden gaan filteren. Juist deze tranparante firewall functionaliteit vind ik zo leuk, kun je zo voor je servers schuiven.. Als het werkt tenminste.

De bridge werkt prima, als ik firewall-type="open" selecteer, werkt alle communicatie alle richtingen op prima. Als ik echter onderstaand script als rules opgeeft, gaat het niet goed..

Eerst mijn configs:

mijn /etc/sysctl.conf:

code:

net.link.ether.bridge.config=fxp0:0,xl0:0
net.link.ether.bridge.ipfw=1
net.link.ether.bridge.enable=1

mijn /etc/rc.conf:

code:

hostname="nmt-frw-01.domein.local"
ifconfig_fxp0="DHCP"
sshd_enable="YES"
firewall_enable="YES"
firewall_type="/etc/rc.firewall.local"
firewall_logging="YES"

mijn /etc/rc.firewall.local

code:

add check-state

# -------------------------------------
# BRIDGE
# -------------------------------------
# Allow all FROM bridge machine
add pass tcp from 192.168.235.201 to any setup keep-state
add pass udp from 192.168.235.201 to any keep-state
add pass ip from 192.168.235.201 to any

# Allow SSH to the bridge machine
add pass tcp from any to 192.168.235.201 22 setup keep-state

# -------------------------------------
# OUT
# -------------------------------------
add pass tcp from any to any in via fxp0 setup keep-state
add pass udp from any to any in via fxp0 keep-state
add pass ip from any to any in via fxp0

# -------------------------------------
# IN
# -------------------------------------
# Allow SSH to all internal hosts
add pass tcp from any to any 22 in via xl0 setup keep-state
# Allow SMTP to all internal hosts
add pass tcp from any to any 25 in via xl0 setup keep-state
# Allow DNS to all internal hosts
add pass udp from any to any 53 in via xl0 keep-state

# -------------------------------------
# ICMP
# -------------------------------------
# Pass 'ping'
add pass icmp from any to any icmptypes 8 keep-state
# Pass error messages generated by 'traceroute'
add pass icmp from any to any icmptypes 3
add pass icmp from any to any icmptypes 11

# -------------------------------------
# REST
# -------------------------------------
add drop log all from any to any

Dit resulteert in de volgende ipfw list:

code:

root@nmt-frw-01# ipfw list
00100 check-state
00200 allow tcp from 192.168.235.201 to any setup keep-state
00300 allow udp from 192.168.235.201 to any keep-state
00400 allow ip from 192.168.235.201 to any
00500 allow tcp from any to 192.168.235.201 dst-port 22 setup keep-state
00600 allow tcp from any to any in via fxp0 setup keep-state
00700 allow udp from any to any in via fxp0 keep-state
00800 allow ip from any to any in via fxp0
00900 allow tcp from any to any dst-port 22 in via xl0 setup keep-state
01000 allow tcp from any to any dst-port 25 in via xl0 setup keep-state
01100 allow udp from any to any dst-port 53 in via xl0 keep-state
01200 allow icmp from any to any icmptypes 8 keep-state
01300 allow icmp from any to any icmptypes 3
01400 allow icmp from any to any icmptypes 11
01500 deny log ip from any to any
65535 deny ip from any to any

Ik kan wel ssh'en naar de bridge zelf (192.168.235.201), maar als ik wil ssh'en naar bijvoorbeeld 192.168.235.5, dan zie ik dit in m'n /var/log/security:

code:

Nov  7 18:18:23 nmt-frw-01 kernel: ipfw: 1500 Deny MAC in via xl0
Nov  7 18:18:58 nmt-frw-01 last message repeated 7 times
Nov  7 18:19:23 nmt-frw-01 last message repeated 5 times
Nov  7 18:19:25 nmt-frw-01 kernel: ipfw: 1500 Deny TCP 192.168.235.12:1277 192.168.235.201:22 in via xl0
Nov  7 18:19:28 nmt-frw-01 kernel: ipfw: 1500 Deny MAC in via xl0
Nov  7 18:20:03 nmt-frw-01 last message repeated 7 times
Nov  7 18:20:29 nmt-frw-01 last message repeated 5 times
Nov  7 18:20:29 nmt-frw-01 kernel: ipfw: 1500 Deny TCP 192.168.235.12:1277 192.168.235.201:22 in via xl0
Nov  7 18:20:34 nmt-frw-01 kernel: ipfw: 1500 Deny MAC in via xl0
Nov  7 18:21:09 nmt-frw-01 last message repeated 7 times

Het vage is dat die SSH connecties dus WEL goed gaan.. Daarnaast wordt er dus van alles aan MAC filtering gedaan zo te zien. Als ik al rule opgeeft 'pass MAC any to any', dan krijg ik die melding niet meer, maar worden ALLE pakketjes toegestaan.. da's nou ook weer niet de bedoeling. Ik zit dus ergens in de knoei met hoe packets bekeken worden denk ik.. Ik dacht wel het e.e.a. te weten van layer2 en layer3 filtering, maar dat valt toch vies tegen..

Als ik ga googlen over de MAC filtering, krijg ik alleen maar resultaten die te maken hebben met hoe je WEL moet MAC filteren.. Maar ik wil alleen layer 3 filteren

Iemand enig idee in welke hoek ik het moet zoeken, want ik kom er niet meer uit...

[axis]

Nou ja, lijk er nu uit te zijn.. het was ARP traffic..


In dit topic heeft iemand dit bovenaan zijn rulesets:

code:

# allow arps (oh yeah, this is important) 
ipfw add allow layer2 mac-type arp

En dan doet m'n firewall precies wat ik van 'm verwacht..

Dat is dus niet consistent met deze mededeling in het freebsd artikel:

There is another important thing to know. When running IP over Ethernet, there are actually two Ethernet protocols in use: one is IP, the other is ARP. ARP does the conversion of the IP address of a host into its Ethernet address (MAC layer). In order to allow the communication between two hosts separated by the bridge, it is necessary that the bridge will forward ARP packets. Such protocol is not included in the IP layer, since it exists only with IP over Ethernet. The FreeBSD firewall filters exclusively on the IP layer and therefore all non-IP packets (ARP included) will be forwarded without being filtered, even if the firewall is configured to not permit anything.

[ Voor 3% gewijzigd door axis op 08-11-2005 09:48 ]