OpenVPN tun0 is down

My FreeBSD version is FreeBSD 8.4-RELEASE-p14, I install OpenVPN 2.3.4 via ports. The Makefile file is:
Code:
$FreeBSD: head/security/openvpn/Makefile 361977 2014-07-15 16:57:39Z adamw $
But I encounter a issue, as follows:


which results in OpenVPN going down.

Please help me! Thanks a lot.
 

Attachments

  • openvpn.jpg
    openvpn.jpg
    64.2 KB · Views: 1,018
  • crash.png
    crash.png
    5 KB · Views: 1,031
That's the port's Makefile. Please post your OpenVPN configuration.
 
My OpenVPN configuration file is as follows:
Code:
port 8899
proto tcp
dev tun
topology subnet
ca keys/ca.crt
cert keys/server.crt
key keys/server.key
dh keys/dh1024.pem
tls-auth /etc/openvpn/keys/ta.key 0 
plugin keys/openvpn-plugin-auth-pam.so login
server 172.16.0.0 255.255.255.0
route 202.121.86.0 255.255.255.0
client-config-dir fixedip
ccd-exclusive
client-to-client
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 4
push "route 192.168.200.0 255.255.255.0"
push "route 192.168.202.0 255.255.255.0"
push "route 192.168.201.0 255.255.255.0"
push "route 192.168.100.0 255.255.255.0"
 
The errors don't seem to have any relation with the configuration you posted. The errors show issues with IPv6 addresses and there are none in your configuration file.
 
Thanks a lot. But with OpenVPN 2.3.2, there is not such a problem. I use the PF firewall. But PF cannot automatically [cannot what? -- mod.] at the system boot time. Every time I manually start PF via: pfctl -f /etc/pf.conf then, currently connecting SSH sessions are closed. Occasionally OpenVPN shuts down during such a problem. After OpenVP has been running for a while, this problem occurs. But it's uncertain exactly when.

I want the PF firewall to automatically start at the system boot time. But PF doesn't start. The /etc/rc.conf file is as follows:

But when I manually start the PF firewall, it prompts as follows:

Maybe this problem resulted from PF not automatically starting, in case of not compiling the kernel, How to solve the problem?

Thanks a lot again.
 

Attachments

  • 20140722104046.png
    20140722104046.png
    1 KB · Views: 838
  • 20140722103901.jpg
    20140722103901.jpg
    10.5 KB · Views: 901
There is no problem with PF. The message you see is normal. Only the ALTQ part doesn't work and you don't use it. In order to get ALTQ working you must compile a custom kernel.
 
Thanks a lot. But why does PF not start automatically at boot time? How to solve this is problem?
 
I have added
Code:
pf_enable="YES"
to /etc/rc.conf, but pf does not yet load pf.conf rules. I do not understand.
 
Please post your /etc/pf.conf. It's possible there's a syntax error in it. That would prevent the rules from being loaded. Also post the output of pfctl -nf /etc/pf.conf (this will load the rules and check for errors but won't apply them).
 
How do you know pf did not automatically start? Do you have an error message? After a reboot, upon the first login does pfctl -sr return no rules loaded?

Guillaume.
 
Yes,after a reboot, when I login to the system, issuing pf -sa returns
Code:
no rules loaded
I must manually load the rules via pfctl -nf /etc/pf.conf

My pf.conf content is as follows:
 

Attachments

  • pfconf.png
    pfconf.png
    6.1 KB · Views: 747
As @SirDice said, the command pfctl -nf /etc/pf.conf will not load the rules, but only check the syntax of /etc/pf.conf and shows an output. Can you show us this output ? Also, at which securelevel are you running?

Guillaume.
 
Last edited by a moderator:
I am sorry! I use pfctl -f /etc/pf.conf to load rules. When running pfctl -nf /etc/pf.conf, I get output as follows:



There is no output.

The system's securelevel is as follows:



Thanks a lot everyone!
 

Attachments

  • pfct-nf.png
    pfct-nf.png
    1.4 KB · Views: 730
  • securelevel.png
    securelevel.png
    2.8 KB · Views: 702
Although not necessary at securelevel -1, you could try to load pf kernel modules in /boot/loader.conf:
Code:
pf_load="YES"
pflog_load="YES"

This way they will be loaded before your /etc/pf.conf file is accessed. Does it change anything?
 
Thanks a lot. I should be as follow content:
Code:
pf_load="YES"
pflog_load="YES"
Add to /boot/loader.conf file.
After rebooting, pf rules still do not load as shown in screenshot:
 

Attachments

  • pfloader.png
    pfloader.png
    9.1 KB · Views: 587
I see no reason as to why it does not load at boot. May be check your /etc/pf.conf permissions, and take a look at /var/log/messages just after a reboot. Check the moment pf should load, if there is any error message.

Guillaume
 
Thanks a lot everyone.I found out PF why not automatically load at the system boot. Reason is PF rules include a rule as follows:
Code:
pass in on tun0 from tun0:network to !192.168.200.208  keep state
when PF starting. OpenVPN yet started. Therefore, tun0 interface inexistence.as follows screenshot:

Meanwhile, I encounter a problem, it is OpenVPN starts two times:

I can't understand why.
Now, how to change pf start order, let pf at openvpn start after start?
 

Attachments

  • pfstarterror.jpg
    pfstarterror.jpg
    83.3 KB · Views: 772
  • startopenvpnissus.png
    startopenvpnissus.png
    11.8 KB · Views: 610
May be try to modify your rule that way:
Code:
pass in on tun0 from (tun0:network) to !192.168.200.208 keep state

Does it work?
 
I modified my pf.conf according to your suggestion, but the problem persists. See the screenshot.



How do I change the starting order?
 

Attachments

  • changepfrule.png
    changepfrule.png
    7.9 KB · Views: 725
I do not know if it's possible to modify the order in which services start. The rule syntax I suggested you is close to the one I'm using on my router, where I use also OpenVPN. I'm using more exactly (extracts):
Code:
vpn="tun0"
nat on $vpn from ($lan:network) to any -> ($vpn:0)

That is not the same rule as you, but I do not have the problem you encounter at start. In my /etc/rc.conf pf is written first, and OpenVPN at the end of the file. However I don't know if it modifies the boot order. Can you check this last point? Then I'm afraid I'm out of ideas.

EDIT: I noticed your forgot one rule, modify also the other rule using "(tun0:network)":
Code:
pass in on tun0 from (tun0:network) to !192.168.200.208 keep state
pass in on tun0 proto udp from (tun0:network) to any keep state

Guillaume
 
Use the up and down options in your configuration file to (re)load the PF ruleset.

Code:
       --up cmd
	      Run command cmd after successful TUN/TAP device open (pre	--user
	      UID change).

	      cmd  consists  of	 a  path  to  script  (or executable program),
	      optionally followed by arguments.	The path and arguments may  be
	      single-  or  double-quoted and/or	escaped	using a	backslash, and
	      should be	separated by one or more spaces.

	      The up command is	useful for  specifying	route  commands	 which
	      route IP traffic destined	for private subnets which exist	at the
	      other end	of the VPN connection into the tunnel.

	      For --dev	tun execute as:

	      cmd   tun_dev   tun_mtu	link_mtu   ifconfig_local_ip	ifcon-
	      fig_remote_ip [ init | restart ]

	      For --dev	tap execute as:

	      cmd  tap_dev tap_mtu link_mtu ifconfig_local_ip ifconfig_netmask
	      [	init | restart ]

	      See the "Environmental Variables"	section	below  for  additional
	      parameters passed	as environmental variables.

	      Note that	if cmd includes	arguments, all OpenVPN-generated argu-
	      ments will be appended to	them to	build an  argument  list  with
	      which the	executable will	be called.

	      Typically, cmd will run a	script to add routes to	the tunnel.

	      Normally	the  up	 script	 is called after the TUN/TAP device is
	      opened.  In this context,	the last command line parameter	passed
	      to  the script will be init.  If the --up-restart	option is also
	      used, the	up script will be called  for  restarts	 as  well.   A
	      restart  is considered to	be a partial reinitialization of Open-
	      VPN where	the TUN/TAP instance is	preserved  (the	 --persist-tun
	      option  will enable such preservation).  A restart can be	gener-
	      ated by a	SIGUSR1	signal,	a --ping-restart timeout, or a connec-
	      tion  reset  when	 the  TCP protocol is enabled with the --proto
	      option.  If a restart occurs, and	--up-restart has  been	speci-
	      fied,  the  up  script  will  be called with restart as the last
	      parameter.

	      The following standalone example shows how the --up  script  can
	      be called	in both	an initialization and restart context.	(NOTE:
	      for security reasons, don't run the following example unless UDP
	      port  9999  is blocked by	your firewall.	Also, the example will
	      run indefinitely,	so you should abort with control-c).

	      openvpn --dev tun	--port 9999 --verb 4  --ping-restart  10  --up
	      'echo up'	--down 'echo down' --persist-tun --up-restart

	      Note  that  OpenVPN also provides	the --ifconfig option to auto-
	      matically	ifconfig the  TUN  device,  eliminating	 the  need  to
	      define  an --up script, unless you also want to configure	routes
	      in the --up script.

	      If --ifconfig is also specified, OpenVPN will pass the  ifconfig
	      local  and  remote  endpoints  on	 the  command line to the --up
	      script so	that they can be used to configure routes such as:

	      route add	-net 10.0.0.0 netmask 255.255.255.0 gw $5
 
gkbsd said:
In my /etc/rc.conf pf is written first, and OpenVPN at the end of the file.
The order in rc.conf is totally irrelevant.
 
Back
Top