OpenVPN and 1.0-BETA1

Numbski

Wiki'ed. Didn't do the nexcom stuff. Try to get to it later

http://wiki.pfsense.com/wikka.php?wakka=Hacom

Okay, now that I'm done hijacking the thread, perhaps I can get back to the business of working on OpenVPN? :P

Numbski

I'm sorry guys, I've had zero time to come back to this. :(

I'm going to make every effort to get back to it next week, but I can't make any promises.

If anyone is up for it, we should get 2 or 3 of us to exchange openvpn connection info so we can add and remove several interfaces for testing. I'm game if anyone wants to PM me.

ecce

Hi!

Sorry that I didn't have time to do the testing, I've been very busy at work, "business as usual"… :(
(Man, I wish I had one of these jobs that would pay me to work for the open source community!)

I have finally got some time to look into this post and do some testing with 1.0BETA2 (The BETA1-OpenVPN build wasn't available any more):

I did a very basic install into two VMWare sessions, and I have tried to test the all the available OpenVPN functionality between those two boxes.
Here are the problems which I have encountered, still TODO's:

openvpn messages not appearing in openvpn log in WebGui but in System log instead
fix client not restarting when enabling disabled client
XML error: not well-formed (invalid token) at line 117 when entering client-specific configuration
fix client not restarting when changing interface configuration/when pf reloads
XML error: not well-formed (invalid token) at line 117 when trying to configure a CRL
firewall rules (their interface assignment) get messed up when interface is being added/removed

I hope I'll find some time this weekend to flash my WRAP at home with the new version, since the server part still seems to run without any problems.

So, what to do next?
Should I try and look into the above problems and then post a patch again?

Marc

sullrich

@ecce:

So, what to do next?
Should I try and look into the above problems and then post a patch again?

Yep, that would be ideal. Or someone else… ;)

fernandotcl

Apparently, for the OpenVPN VPN to work, you need to have a "pass in on tunX" and a "pass out on tunX" rule. Problem is, the pfSense user rules don't all you to create "pass out" rules.

So, instead of letting the user allow what goes through the tun interfaces, adding "pass out on tunX" and "pass in on tunX" in filter.inc depending on the number of tun interfaces configured sounds reasonable. It'd save us a lot of trouble, simplifying a lot things, I think.

The only drawback of this approach is that the user wouldn't have granulated control over the tun interfaces, but the user can control the access to the VPN using the rules for the interface used to connect to the VPN instead.

Or am I overlooking the issue?

sullrich

We create pass out rules on bridges, too so this would be the solution.

create_firewall_outgoing_rules_to_itself() in /etc/inc/filter.inc contains these items so we simply need to ammend this to include tun rules if OpenVPN is in effect.

Someone want to take this on and submit a patch?

sullrich

Nevermind, I did it myself.

http://cvstrac.pfsense.com/chngview?cn=10547

Let me know if it works.

Numbski

Updated filter.inc here and testing now. Appears to work beautifully. Now if I could only figure out why my linksys wrt54gs recently decided to stop routing across the openvpn…

BTW, there's something that is just driving me nuts. Is there a reason that when using a pre-shared key there is a "0" appended at the end of the line?

secret /var/db/ovpn_srv_psk_tun0.pem 0

I keep having to manually delete the zero and restart openvpn mysellf. I don't want to go modding the code if there's a legit reason for it being there...I can't think of one though.

Here's the error generated if I leave it there:

Wed Mar 22 14:12:16 2006 Authenticate/Decrypt packet error: packet HMAC authentication failed

Deletion of the zero resolves the problem.

Numbski

While we're on the matter, I need to allow routing to networks on the other side of the tunnel. I'm finding that I can't use the route-up command in the advanced options. For example:

route-up 172.16.31.0/24 10.0.1.3

Where 10.0.1.3 is the IP of this side of the openvpn tunnel. OpenVPN dies with this error:

Wed Mar 22 14:00:07 2006 Initialization Sequence Completed
Wed Mar 22 14:03:13 2006 event_wait : Interrupted system call (code=4)
route: must be root to alter routing table
Wed Mar 22 14:03:13 2006 ERROR: FreeBSD route delete command failed: shell command exited with error status: 77
Wed Mar 22 14:03:13 2006 SIGTERM[hard,] received, process exiting

Oops. I can of course either add a static route or manually work around it otherwise, but I don't think that's intended behavior. Individual tunnels should be able to bring up or take down routes via the advanced options, right?

Numbski

Aside from the route-up issue above, and the fact that I have to keep manually removing that zero, your patch is functioning well. I guess I get to go code-digging to find where that zero is being generated and comment it out…

EDIT: Found it. /etc/openvpn.inc, line 420/1500

Originally:


                $ovpn_config .= "secret {$g['vardb_path']}/ovpn_srv_psk_{$tun}.pem 0\n";

Copied that line, commented out the first and removed the space and zero from the end of the line.

Also on line 991, did the same thing:


               $ovpn_config .= "secret {$g['vardb_path']}/ovpn_cli_psk_{$tun}.pem 0\n";

That should resolve that problem. The only other thing that comes to mind is flag –log /var/log/openvpn_tunx.log should be created instead of what is there now, which is just "openvpn statistics".

Numbski

Just a head's up. The inability to place a route-up statement in expert mode is a bigger problem than I thought. What happens is that if you define a static route to work around the issue, is that if for some reason your tunnel is not up, you'll start getting arplookup x.x.x.x is not on local network errors, as the route gets assigned to something other than tunx (since it doesn't exist).

So that's no good. It looks as though we need either temporary privelege escalation, or stop running as nobody and run it as root (eep!!!!).

Numbski

….and there's more. It seems that rules don't like to have "TUNx Network" chosen as a source or destination in a rule, as the variable does not resolve itself correctly:


# cat /tmp/notices
a:1:{i:1143065694;a:5:{s:2:"id";s:11:"filter_load";s:6:"notice";s:328:"There were error(s) loading the rules: /tmp/rules.debug:143: syntax error
/tmp/rules.debug:144: syntax error
pfctl: Syntax error in config file: pf rules not loaded The line in question reads [143]: pass in quick on $TUN0 from /30 to 10.10.101.0/24 keep state  label "USER_RULE: Allow all traffic from tunnel to Shadwick Home." ";s:3:"url";s:0:"";s:8:"category";s:13:"Filter Reload";s:8:"priority";i:1;}}

pass in quick on tun0 from /30 huh? :P That should be the IP address of tun0, which in this case would be 10.0.2.1/30 (I think that's right. It hits a piece of subnetting screwy-ness in my brain. /32 allows no subnet bits for the network. /31 steals 1 bit for the network, and /30 steals 2 host bits. I'm not sure what the practical difference in a subnet situation there is between /32, /31, and /30. /29 is the first subnet mask that begins to make any sense, giving you 4 host bits for the network, 1 for network, 1 for broadcast, and 2 hosts…).

Long story short, we have a variable that doesn't get resolved someplace.

Numbski

Well this sucks. Even with the patch above, we have a problem with not having root permissions and adding/removing route information:

Mar 23 03:40:04 openvpn[9162]: event_wait : Interrupted system call (code=4)
Mar 23 03:40:04 openvpn[9162]: event_wait : Interrupted system call (code=4)
Mar 23 03:40:04 openvpn[9162]: ERROR: FreeBSD route delete command failed: shell command exited with error status: 77
Mar 23 03:40:04 openvpn[9162]: ERROR: FreeBSD route delete command failed: shell command exited with error status: 77
Mar 23 03:40:04 openvpn[9162]: SIGTERM[hard,] received, process exiting
Mar 23 03:40:04 openvpn[9162]: SIGTERM[hard,] received, process exiting

This came up after a rules reload. Grr…..

EDIT: Scratch that. I failed to copy a file correctly. All is well with the above patches, save for route-up statements. Any suggestions on how to get those working would be much appreciated!

Numbski

Just poking my head in to say that the above patches are indeed stable. I've been running on them for 5 days, reboots included, without issue.

I've been putting my brain to the task of getting the route-up statements to run with escalated privs, without success. Perhaps we add form fields in the setup pages for adding additional routes and create and tear down routes outside of OpenVPN, but one would think you could do this without re-inventing the wheel, no?

Numbski

…and I think I've found my issue. --route-up isn't the command I want. From the OpenVPN 2.1 man pages:


--route network/IP [netmask] [gateway] [metric]
    Add route to routing table after connection is established. Multiple routes can be specified. Routes will be automatically torn down in reverse order prior to TUN/TAP device close.

    This option is intended as a convenience proxy for the route(8) shell command, while at the same time providing portable semantics across OpenVPN's platform space.

    netmask default -- 255.255.255.255

    gateway default -- taken from --route-gateway or the second parameter to --ifconfig when --dev tun is specified.

    The default can be specified by leaving an option blank or setting it to "default".

    The network and gateway parameters can also be specified as a DNS or /etc/hosts file resolvable name, or as one of three special keywords:

    vpn_gateway -- The remote VPN endpoint address (derived either from --route-gateway or the second parameter to --ifconfig when --dev tun is specified).

    net_gateway -- The pre-existing IP default gateway, read from the routing table (not supported on all OSes).

    remote_host -- The --remote address if OpenVPN is being run in client mode, and is undefined in server mode.

So I've been using the wrong command altogether. On both sides. D'oh. :\

So I'll give this a whirl and see how it goes.

Numbski

That did it. Man I'm an idiot. :P

It would probably behoove us to provide an interface for adding additonal routes on a per-tunnel basis from the OpenVPN config pages.

One little request to the more php-literate amongst us…would it be possible to use the Description field as the name that appears in the firewall rules and elsewhere in the interface as opposed to TUN0, or TAP0, etc? My clients are used to being able to name tunnels (from my dirty hack back at christmas) and like the ability to do that. Just wondering. ;)

sullrich

Note as of April 8th snapshots OpenVPN has been replaced with a completely rewritten version done by Fernando Lemos.

Please test!

drakkan

@sullrich:

Note as of April 8th snapshots OpenVPN has been replaced with a completely rewritten version done by Fernando Lemos.

Please test!

I successfully configured a site to site vpn using openvpn pfsense was the "client" and was a natted box,

here are my notes:

VPN->OPENVPN-Client

Chose UDP as protocol and select the appropriate value for remote server and remote port

choose PKI as authentication method and past ca certficate and client certificate and key

select lzo-compression

and add the following to the custom options:

dev tun; ifconfig 10.1.0.2 10.1.0.1; tls-client; user nobody; group nobody; persist-tun; persist-key; verb 3

on the other box (linux in my case) I have the following config file:

dev tun
ifconfig 10.1.0.1 10.1.0.2
up /etc/openvpn/office.up
tls-server
dh /usr/share/openvpn/easy-rsa/keys/dh1024.pem
ca /usr/share/openvpn/easy-rsa/keys/ca.crt
cert /usr/share/openvpn/easy-rsa/keys/server.crt
key /usr/share/openvpn/easy-rsa/keys/server.key
push "route 192.168.66.0 255.255.255.0"
port 1194
user nobody
group nogroup
chroot /etc/openvpn/chroot
comp-lzo
ping 15
ping-restart 45
ping-timer-rem
persist-tun
persist-key
verb 3

in office.up I setup routing

You need a firewall rule to allow vpn traffic, I add a new interface called and assigned tun0 to it, you can give an arbitrary ip address, the right ip address will be assigned when openvpn come up and finally add a pass all rule on this new interfaces,

reboot pfsense box and it works!

I'm not sure if the way I choiche to allow vpn traffic is the best one, however it works for me. Do you think there are alternative/best way to allow vpn traffic?

If I setup another pfsense box and configure a cluster, I have to disable openvpn tunnel on the backup node, would be useful a way to have failover also for openvpn,

thanks for pfsense,

regards
drakkan

Always

That's great drakan, I'm gonna try it out now. Tried it on friday and the firewall hang. I needed to restore to factory defaults because webconfigurator wasn't reachable through any of the interfaces.

Thanks again for your tests.

BTW: what version where you running? RC1a?