VPN Stops Working after 12 hours
-
Are your clients on a dynamic IP?
What does the log show, when you loose the link? -
Yep, clients are on dynamic ip on adsl connections. HQ is on a static ip.
No messages in the clients or openvpn server logs, it seems as if the OpenVPN connection is still up but pings just stop working, apart from below which is from the site1 box (192.168.10.0/24):
Mar 6 07:04:44 openvpn[369]: OpenVPN 2.0.6 i386-portbld-freebsd6.2 [SSL] [LZO] built on Sep 13 2007
Mar 6 07:04:44 openvpn[369]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Mar 6 07:04:44 openvpn[369]: WARNING: file '/var/etc/openvpn_client0.key' is group or others accessible
Mar 6 07:04:44 openvpn[369]: LZO compression initialized
Mar 6 07:04:44 openvpn[370]: UDPv4 link local (bound): [undef]:1194
Mar 6 07:04:44 openvpn[370]: UDPv4 link remote: x.x.x.x:1194
Mar 6 07:04:55 openvpn[370]: [router-hq.rotaryhumm.com] Peer Connection Initiated with x.x.x.x:1194
Mar 6 07:04:56 openvpn[370]: gw 169.254.100.2
Mar 6 07:04:56 openvpn[370]: TUN/TAP device /dev/tun0 opened
Mar 6 07:04:56 openvpn[370]: /sbin/ifconfig tun0 172.16.1.6 172.16.1.5 mtu 1500 netmask 255.255.255.255 up
Mar 6 07:04:56 openvpn[370]: /etc/rc.filter_configure tun0 1500 1542 172.16.1.6 172.16.1.5 init
Mar 6 07:04:57 openvpn[370]: ERROR: FreeBSD route add command failed: shell command exited with error status: 1
Mar 6 07:04:57 openvpn[370]: Initialization Sequence CompletedI presume the route add command failed is due to it the site 1 client (192.68.10.0/24) getting pushed the route 192.168.10.0/24 however this needs to be sent so all clients know they can connect to this network via the openvpn tunnel as per the hub/spoke setup.
The routing table on the HQ pfsense box is:
172.16.1/24 172.16.1.2 UGS 0 56 1500 tun0
172.16.1.2 172.16.1.1 UH 3 0 1500 tun0
192.168.10 172.16.1.2 UGS 0 14191 1500 tun0
192.168.20 172.16.1.2 UGS 0 4036 1500 tun0The above seems correct.
On the client pfsense box (site 1) the routing table is:
default 169.254.10.1 UGS 0 162 1500 rl3
127.0.0.1 127.0.0.1 UH 0 0 16384 lo0
169.254.10/30 link#4 UC 0 0 1500 rl3
172.16.1/24 172.16.1.5 UGS 0 0 1500 tun0
172.16.1.5 172.16.1.6 UH 3 0 1500 tun0
192.168.2 172.16.1.5 UGS 0 16 1500 tun0
192.168.10 link#1 UC 0 0 1500 rl0
192.168.20 172.16.1.5 UGS 0 0 1500 tun0Again, to me the above seems correct also! The OpenVPN link is definetly coming up as i can see that in the client and server logs.
The strangest thing is the config works, stops working, gets changed & works, returned to original config and works again! I tried again repeating this process and now its not working. Im pulling my hair out, have run OpenVPN before and not had as many problems as this.
Any ideas much appreciated,
Thanks
-
Could you post the server and the client configs?
It could be that when a client changes his IP/port/whatever the link stops working.Btw: are you using a PKI? It seems to me like this because of: Mar 6 07:04:56 openvpn[370]: /etc/rc.filter_configure tun0 1500 1542 172.16.1.6 172.16.1.5 init
If you are using site-to-site better use a shared key and not a PKI.
With a PKI you would need client specific iroute command and just normal /push's and /route's
-
Hi, dont have the setup xml files to hand as im at home now but in summary:
Server has local network set to 192.168.2.0/24.
Dynamic DHCP clients are enabled.
Addresses are assigned to clients 172.16.1.0/24
No remote address has been entered (this is since is a multi-site to site config)
The following routes are used:push "route 192.168.2.0 255.255.255.0";
push "route 192.168.10.0 255.255.255.0";
route 192.168.10.0 255.255.255.0;
push "route 192.168.20.0 255.255.255.0";
route 192.168.20.0 255.255.255.0;Under the custom client config for the server box i have entered the CN name of the site 1 pfsense boxes certificate and under that i have entered:
iroute 192.168.10.0 255.255.255.0
i understand this to mean that this tells openvpn internally that 192.168.10.0 sits behind this client. The route in the main config of 192.168.10.0 is to direct traffic to the tun0 interface and then the internal routing of openvpn can apply.
I believe i do need to run openvpn in PKI as i would not be able to assign specific subnets to specific clients like the above scenario of using iroute. From my perhaps blinkered understanding i dont think this is possible with shared keys? Please see this link: http://openvpn.net/archive/openvpn-users/2005-02/msg00261.html
Thanks so much for the time so far.
-
You can find the openVPN configs in the path: /var/etc/
(just use the command line to less the files)Regarding PKI vs. SKI
What you are doing right now should work. But in my opinion the roadwarriors should be separated from the site-to-site links.
–> running multiple instances of OpenVPN with different tasks.
PKI for RoadWarriors
SKI for site-to-site -
Hi, setup a Debian box at home and got in first time no problem as a client. Very strange.
Config file is as follows:
writepid /var/run/openvpn_server0.pid
#user nobody
#group nobody
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
dev tun
proto udp
cipher BF-CBC
up /etc/rc.filter_configure
down /etc/rc.filter_configure
client-to-client
server 172.16.1.0 255.255.255.0
client-config-dir /var/etc/openvpn_csc
push "route 192.168.2.0 255.255.255.0"
lport 1194
push "dhcp-option DNS 192.168.2.10"
push "dhcp-option WINS 192.168.2.10"
ca /var/etc/openvpn_server0.ca
cert /var/etc/openvpn_server0.cert
key /var/etc/openvpn_server0.key
dh /var/etc/openvpn_server0.dh
comp-lzo
persist-remote-ip
float
push "route 192.168.2.0 255.255.255.0"
route 192.168.10.0 255.255.255.0
push "route 192.168.20.0 255.255.255.0"
route 192.168.20.0 255.255.255.0I checked the routing table of my client and it seems ok.
For the site to site link i believe we have to use PKI and have no other choice, this is borne from the fact OpenVPN needs a way of identifying what subnet lies behind what client… having the CN name of the clients certificate and identifying a client against this gives us this ability. So i dont think the multi-site to site link would work with static keys? I do agree i will separate the road warriors from site to site links, i will do this by running a new instance on a separate port should the need arise for road warriors.
Anyways, i will setup the same config with a debian box at both ends and see if i get any joy. Debian Sarge -> pfSense seems to work.
Will put on ping test for a while and see if i get any packet loss.
Regards,
Chris
-
For the site to site link i believe we have to use PKI and have no other choice, this is borne from the fact OpenVPN needs a way of identifying what subnet lies behind what client… having the CN name of the clients certificate and identifying a client against this gives us this ability. So i dont think the multi-site to site link would work with static keys? I do agree i will separate the road warriors from site to site links, i will do this by running a new instance on a separate port should the need arise for road warriors.
I disagree. You can setup a SKI for every site-to-site connection.
Given the administration effort is a bit bigger but troubleshooting gets easier.
In your case where you have 2 offsites that would mean 2 SKI's for the site-to-site and 1 PKI for the Roadwarriors
–> 3 Separate Server instances.OpenVPN can distinguish the different site-to-sites because like this, the different connections are on different virtual interfaces.
Anyway: i think i know why your config is not working:
persist-remote-ip–persist-remote-ip
Preserve most recently authenticated remote IP address and port number across SIGUSR1 or --ping-restart restarts.SIGUSR1
Like SIGHUP, except don't re-read configuration file, and possibly don't close and reopen TUN/TAP device, re-read key files, preserve local IP address/port, or preserve most recently authenticated remote IP address/port based on –persist-tun, --persist-key, --persist-local-ip, and --persist-remote-ip options respectively (see above).This signal may also be internally generated by a timeout condition, governed by the --ping-restart option.
This signal, when combined with --persist-remote-ip, may be sent when the underlying parameters of the host's network interface change such as when the host is a DHCP client and is assigned a new IP address. See --ipchange above for more information.
I remember there was once a hread about something similar.
It can well be that this is an error in the auto-generation of the config file.Can the developer who did the OpenVPN-stuff take a look at that?
-
Thnx. I didnt touch the config file all settings were done through the web interface. ???
Thanks again for the help, lets hope this is a bug becuase the debian box has been conntect rock solid all day to the pfsense HQ box.
Cheers
-
If this was a bug I am sure others would have reported it by now….
-
I'll try to recreate this (as soon as i find the time….)
-
Well i can confirm Debian box as OpenVPN client to pfsense server has been up solid for over 24 hours now no problem. Link is still solid. This is probably something to do with the client, i will post the client configs tomorrow.
I appreciate what you say about bugs and reporting, i am sure it would have been reported also and maybe this is something i have done wrong but one things for sure i have seen weird stuff like this before like with OpenWRT and netfilter working ok with NAT redirects for 24 hours and then randomly remapping to a different port for no reason!
Thanks for the time really appreciate it.
Regards,
Chris
