On Tuesday 18 July 2006 16:49, Kevin Elliott wrote: > Thanks for the reply James. > > The pf rules resolves to the following three rules actually: > > @9 pass quick on lo0 all > @10 pass quick on sis1 all > @11 pass quick on tun0 all I would just put all three rules in specifically, instead of using the catchall rule. (That's just me - pf should not care one way or another.) > > so I'm pretty sure tun0 traffic is being passed. I actually find that > the less rules the more condensed the rules the easier time I have > keeping track of them since I have multiple interfaces that have > similar filtering needs. > > All your network-related advice went right over my head. I'm not too > good with that stuff. However I want to add something. I was doing > some testing today and I could get the tunnel up but I decided to > leave my ethernet cable on my laptop plugged in and amazingly enough > traffic was passing through the tunnel even my ping traffic to the > outside world. Hmm. There are a variety of things that make me uncomfortable about this setup. Take another look at your pf.conf. If I recall correctly, pf uses the last match pass unlike iptables which uses a first match pass. Start off with: block all you've blocked all traffic, in or out, on all interfaces. Now I'm specifically looking at your wlan_if rules: pass in quick on $wlan_if proto udp from any to $wlan_if port 1194 keep state --OK, no you let traffic _IN_ on wlan_if, but only UDP 1194 OpenVPN traffic. Nothing else. antispoof quick for { $wan_if $lan_if $wlan_if } --And now you set up anti-spoofing. Your "block all" is still blocking traffic _OUT_ for wlan_if, correct? So changing the rule to read pass quick on $wlan_if proto udp from any to $wlan_if port 1194 keep state might help. Remember that you are passing traffic over tun0, which is a virtual interface that depends on wlan_if being up. However! I do not think you are actually using your wireless NIC to pass traffic anywhere but itself, so the pf rules for wlan_if don't matter. Here's what I think is going on: ----------------------------------- On the client side: Mon Jul 17 19:10:30 2006 /sbin/route add -net 192.168.101.254 192.168.100.254 255.255.255.255 add net 192.168.101.254: gateway 192.168.100.254 What the command appears to do is add a network (192.168.101.254 - the IP address of your OpenBSD wireless NIC) with the gateway 192.168.100.254 (the IP address of your OpenBSD wired NIC) with the netmask of 255.255.255.255. Lets look at each part, going backwards: That netmask is strange. It means your wireless NIC is on a network of exactly one address (which just happens to belong to the wireless NIC on the server). Although route accepted the syntax, it isn't really a valid netmask - you need a network address, a broadcast address, and at least one host address. The smallest legal network is four addresses. In your case, the network would be 192.168.101.252, two hosts at .253 and .254, and the broadcast at .255. Using the 255.255.255.255 netmask, your wireless card can only talk to itself and no other interface on it's network. Luckily you have two network connections, so your computer can still route traffic. The gateway is also strange. Normally you want a gateway to be on the same network as the one you are describing. It works in your case because both networks are directly connected to your computer, so your computer knows how to get to 192.168.100.254 - by going over the wired network. That explains why you need your wired connection up to use the VPN tunnel. Your routing table says "If I want to put any packets across the 192.168.101.254 network that are not for an address on the network, I need to send them to 192.168.100.254." Bring the wired connection down, you no longer have a gateway. The network address isn't what people would normally type, although it is legal. You usually enter the network address of a network being added, not the address of a host on the network. The netmask lets the computer figure out what you mean, so it still works though. And in the case of a 255.255.255.255 netmask, you don't have much choice anyway! How is your laptop getting an IP address for it's wireless NIC? DHCP from the OpenBSD box, static? ----------------------------------- On the server side: Jul 17 07:06:40 soekris openvpn[15192]: /sbin/ifconfig tun0 10.8.0.1 10.8.0.2 mtu 1500 netmask 255.255.255.255 up Once again, the netmask breaks things. That network isn't useable since there is no room for another computer on the same network. Where is it supposed to send packets? ----------------------------------- On the OpenVPN installation I set up at work, all OpenVPN tunnels had a netmask of 255.255.255.252 - a small, two host network, just server and client. All of the normal, unencrypted interfaces the tun interfaces piggybacked on had normal, legal netmasks. Not one 255.255.255.255 anywhere. Cheers, James ------------------------------------ The Juneau Linux Users Group -- http://www.juneau-lug.org This is the Juneau-LUG mailing list. To unsubscribe, send an e-mail to juneau-lug-request@xxxxxxxxxxxxx with the word unsubscribe in the subject header.