[juneau-lug] Re: OpenVPN continued...

  • From: James Zuelow <e5z8652@xxxxxxxxxx>
  • To: juneau-lug@xxxxxxxxxxxxx
  • Date: Tue, 18 Jul 2006 18:19:08 -0800

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.

Other related posts: