Hi, I created a virtual instance of OpenBSD 5.0 x64 RELEASE edition using VirtualBox and set it up to be used as router/gateway with NAT.
Taking this: http://www.openbsd.org/faq/pf/example1.html as an example for practically getting to know packet filter which I've never used before and get more familiar with OpenBSD in itself. Through reading the FAQ on PF and trying to understand the way it works can someone clarify that the rule weightings are in bottom-up order..... what I'm trying to clarify is that if I use a pseudo Cisco ACL statement: deny any any permit ip 1.1.1.1 any ip 2.2.2.2 80 line 2 with permit will **never** get matched because there is an implicit deny statement before which has full weighting. Therefor one must first specify the permit then the deny in order for the ACL to have relevance. In Pack Filter this seems to be the reverse according to the example page shown above or the FAQ: http://www.openbsd.org/faq/pf/filter.html meaning that using PF syntax, something like: block in log pass out quick antispoof quick for { lo $int_if } pass in on egress inet proto tcp from any to (egress) \ port $tcp_services will block everything from the statement: "block in log" but if a "pass" statement is put after the filter's "block" statement the weighting will be on the "pass" line and hence a match will try to be determined. In accordance to the above I activated RIPD, took down packet filter using: pfctl -d and setup a connection to my router/gateway. Once everything was working, I activated packet filter again using: pfctl -e and restarted RIPD for good measure: /etc/rc.d/ripd restart All was good and RIPD wasn't able to send or receive any updates.... - actually due to the customization of Exmaple1 from the FAQ, I think RIP updates were being sent but not able to be received! --please correct me if wrong. So adding the line: pass in on egress inet proto tcp from any to (egress) \ port $tcp_services #--> pass in on egress inet proto udp from any to (egress) \ port $udp_services in the mix, RIP information was now being passed internally **to** OpenBSD (but not through to the other side of the NAT). The major issue I'm having with all of this is that I can't see anything! Even SSH'ing into the OBSD instance using tcpdump, from the example shown here: http://www.openbsd.org/faq/pf/logging.html [quote] > > # tcpdump -n -e -ttt -r /var/log/pflog port 80 > > This can be further refined by limiting the display of packets to a > certain host and port combination: > > # tcpdump -n -e -ttt -r /var/log/pflog port 80 and host 192.168.1.3 > > The same idea can be applied when reading from the pflog0 interface: > > # tcpdump -n -e -ttt -i pflog0 host 192.168.4.2 > [/quote] I get lines stating: Mar 02 16:38:38.875426 rule 3/(match) block in on em0: 192.168.0.1.520 > 255.255.255.255.520: RIPv2-resp [items 3]: {0.0.0.0}(1)[|rip] [tos 0xc0] which means that information is being matched by rule 3 and being blocked! However, running tcpdump without as many restrictions directly on interface em0 (external interface): tcpdump port 520 (automatically defaults to int. em0) 16:41:18.563311 OpenBSD.optiplex-networks.com.route > rip2-routers.mcast.net.route: RIPv2-resp [items 2]: {88.88.88.0/255.255.254.0}(1) {192.168.0.0/255.255.255.0}(16) [tos 0xc0] [ttl 1] 16:41:24.354945 192.168.0.1.route > 255.255.255.255.route: RIPv2-resp [items 3]: {0.0.0.0}(1) {192.168.1.0/255.255.255.0}(1) {192.168.2.0/255.255.255.0}(1) [tos 0xc0] Which also doesn't make sense as the router seems to be using Broadcast for RIP while OpenBSD is sending the updates to a multicast address located at 224.0.0.9:520. Neither of which however, tells me what the system is doing.... in terms of diagnostic or verbose output of if packet filter is accepting or rejecting this information. Taken from: ripctl: > # ripctl show fib > flags: * = valid, R = RIP, C = Connected, S = Static > Flags Destination Nexthop > *S 0.0.0.0/0 192.168.0.1 > *R 0.0.0.0/0 192.168.0.1 > *C 88.88.88.0/23 link#2 > *S 127.0.0.0/8 127.0.0.1 > *C 127.0.0.1/8 link#0 > * 127.0.0.1/32 127.0.0.1 > *C 192.168.0.0/24 link#1 > *S 192.168.0.55/32 127.0.0.1 > *R 192.168.1.0/24 192.168.0.1 > *R 192.168.2.0/24 192.168.0.1 > *S 224.0.0.0/4 127.0.0.1 > # ripctl show neighbor > ID State Address Iface Uptime > 192.168.0.1 ACTIVE/ACTIVE 192.168.0.1 em0 00:00:38 > # ripctl show fib rip > flags: * = valid, R = RIP, C = Connected, S = Static > Flags Destination Nexthop > *R 0.0.0.0/0 192.168.0.1 > *R 192.168.1.0/24 192.168.0.1 > *R 192.168.2.0/24 192.168.0.1 Which shows from the rip side of things that everything's fine..... or using: > # pfctl -ss > all tcp 192.168.0.55:22 <- 192.168.0.82:32929 > ESTABLISHED:ESTABLISHED > all udp 88.88.88.1:520 -> 224.0.0.9:520 SINGLE:NO_TRAFFIC > all udp 192.168.0.55:520 -> 224.0.0.9:520 SINGLE:NO_TRAFFIC > # pfctl -si > Status: Enabled for 0 days 05:11:04 Debug: err > > Interface Stats for em0 IPv4 IPv6 > Bytes In 413607 0 > Bytes Out 932059 0 > Packets In > Passed 4516 0 > Blocked 993 0 > Packets Out > Passed 5525 0 > Blocked 0 0 > > State Table Total Rate > current entries 3 > searches 6291 0.3/s > inserts 506 0.0/s > removals 506 0.0/s > Counters > match 826 0.0/s > bad-offset 0 0.0/s > fragment 0 0.0/s > short 303 0.0/s > normalize 0 0.0/s > memory 0 0.0/s > bad-timestamp 0 0.0/s > congestion 0 0.0/s > ip-option 0 0.0/s > proto-cksum 0 0.0/s > state-mismatch 0 0.0/s > state-insert 0 0.0/s > state-limit 0 0.0/s > src-limit 0 0.0/s > synproxy 0 0.0/s But where are the IP addresses and ports in the above output??? The man pages don't claim to show this information..... Would I therefor need to add something like: log to this line: pass in on egress inet proto udp from any to (egress) \ port $udp_services effectively making it: pass in on egress inet proto udp from any to (egress) \ port $udp_services log ??? I know I can just add restart and test but as per the above there's a lot of things I haven't quite understood 100% so any handy and useful explanations would really be appreciated :-) Many thanks, Kaya
