[juneau-lug] Re: OpenVPN continued...
- From: "Kevin Elliott" <woolsherpahat@xxxxxxxxx>
- To: juneau-lug@xxxxxxxxxxxxx
- Date: Wed, 19 Jul 2006 16:22:39 -0800
Hmmm. This is very odd. Once again, thanks for your help explaining
the more esoteric stuff. My networking knowledge is pretty basic.
I'll start with the easy stuff first. Pf does indeed match the last
rule in the set as you mentioned. The quick command will
automatically match the packet to that rule and skip the rest of set.
In theory the only traffic traveling over the wireless NIC should be
OpenVPN (1194 UDP) stuff to initialize the tunnel.
I modified the rule in question to allow packets to path in both
directions. However, I am fairly sure pf isn't the problem since my
clients are able to reach the OpenVPN server on the router:
UDPv4 link remote: 192.168.101.254:1194
If I comment out the rule the VPN clients fail at this point.
After reading through my VPN logs with a full night's sleep and your
comments as a guide, I believe I understand the problem. What I don't
understand is why this is happening.
My router setup is pretty standard.
Sis0 is my upstream link to the internet and it's configured
dynamically with
dhclient.
Sis1 is my local CAT5 network. It's should be operating as
192.168.100.254 on
192.168.100.0/24 with a netmask of 255.255.255.0.
Ath0 is my wireless NIC and it should be operating as 192.168.101.254 on
192.168.101.0/24 with a netmask of 255.255.255.0.
Tun0 should be 10.0.8.0 with a netmask of 255.255.255.0.
I'm using DHCP and if the VPN server is turned off and I open up
$wlan_if to pass all traffic then everything seems to work fine. All
my wireless clients get regular 192.168.101.0/24 leases. Here's my
dhcpd.conf if you'd like to take a look:
option domain-name "local";
option domain-name-servers 209.165.131.12, 209.165.131.13;
subnet 192.168.100.0 netmask 255.255.255.0 {
option routers 192.168.100.254;
range 192.168.100.1 192.168.100.253;
}
subnet 192.168.101.0 netmask 255.255.255.0 {
option routers 192.168.101.254;
range 192.168.101.1 192.168.101.253;
Sooo... if I understand what's happening is VPN is pushing a
non-routable network configuration on the wireless NIC and tunnel
interface. The question is why?
Here's something interesting from my VPN server output:
/sbin/ifconfig tun0 10.8.0.1 10.8.0.2 mtu 1500 netmask 255.255.255.255 up
It brings the tunnel interface up with 255.255.255.255 netmask which
if I understand correctly has only enough addresses for the interface
itself. Right after that though the VPN server pushes this route to
the kernel:
/sbin/route add -net 10.8.0.0 10.8.0.2 -netmask 255.255.255.0
Which as far as I can tell is correct.
Now the VPN configuration file says nothing about the 255.255.255.255
netmask. Here's the relevant line:
server 10.8.0.0 255.255.255.0
So what gives? My limited understanding is that the exchange works like this:
1)The VPN client requests a connection from 192.168.101.254 1194 UDP
over 192.168.101.0/24.
2)VPN server does it's PKI key authentication thing and tells OpenBSD
to open up a tunnel interface with IP address of 10.0.8.1 and a
netmask of 255.255.255.0.
3)VPN server tells the client to open up a tunnel interface with an IP
address on 10.0.8.0 255.255.255.0.
4)Everything works!
It seems to be breaking down at step 2.
In other news I did get the client to get the correct gateway by
modifying my server configuration to not redirect gateways and not
using the wired network to start the VPN tunnel so I suppose that is a
good thing.
Wed Jul 19 16:12:50 2006 gw 192.168.101.254
More netmask wierdness though:
Received control message: 'PUSH_REPLY,route 10.8.0.0
255.255.255.0,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5'
Okay, that looks alright to me but then we have this:
Wed Jul 19 16:12:50 2006 /sbin/ifconfig tun0 10.8.0.6 10.8.0.5 mtu
1500 netmask 255.255.255.255 up
Wed Jul 19 16:12:50 2006 /sbin/route add -net 10.8.0.0 10.8.0.5 255.255.255.0
add net 10.8.0.0: gateway 10.8.0.5
So yeah once again that 255.255.255.255 netmask shows up. I'm in the
dark on why this is happening. I think the problem lies somewhere in
the VPN configuration although I'm not quite sure where. It should be
using the 255.255.255.0 networks.
Anyways, once again thanks for your help and patience.
~Kevin Elliott
On 7/18/06, James Zuelow <e5z8652@xxxxxxxxxx> wrote:
> 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.
>
------------------------------------
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: