[Solved] VPN dies after about a day

B00k3r_D3w1tt

Hello,

I'm having a weird issue with openvpn 2.3.2 i686-redhat on a CentOS 6.5 server. After about a day or so the VPN just seems to die, if I reboot the server everything starts working again and clients can connect.

Here is a copy of my server.conf:

-------------------------------------

port 1194
proto udp
dev tap
script-security 2
up "/etc/openvpn/up.sh br0 eth0"
ca ca.crt
cert vpn.crt
key vpn.key
dh dh2048.pem
ifconfig-pool-persist ipp.txt
server-bridge 10.0.1.202 255.255.252.0 10.0.2.151 10.0.2.200
push ???dhcp-option DNS 10.0.0.11???
keepalive 10 120
tls-auth ta.key 0
cipher AES-256-CBC
comp-lzo
max-clients 45
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
log openvpn.log
verb 6
mute 20

-------------------------------------

And a copy of my client.conf:

-------------------------------------

client
dev tap
proto udp
remote vpn.fake.com 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert [client name].crt
key [client name].key
ns-cert-type server
tls-auth ta.key 1
cipher AES-256-CBC
comp-lzo
verb 3

-------------------------------------

I removed the actual server hostname and the client names in the config files.

-------------------------------------

Also, here is my iptables setup (the commands I issued when I set it up):

-------------------------------------

o iptables -A INPUT -i lo -j ACCEPT
o iptables -A INPUT -i tap0 -j ACCEPT
o iptables -A INPUT -p udp -m udp --dport 1194 -j ACCEPT
o iptables -A INPUT -p tcp -s 10.0.0.0/22 -m tcp --dport 22 -j ACCEPT
o iptables -I INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
o iptables -P OUTPUT ACCEPT
o iptables -P INPUT DROP

-------------------------------------

Here is part of the log (I can't paste the whole thing because it's too big, this is the beginning and end of it):

-------------------------------------

First 200 lines:

Tue Apr 15 08:06:40 2014 us=705650 Current Parameter Settings:
Tue Apr 15 08:06:40 2014 us=706021 config = 'server.conf'
Tue Apr 15 08:06:40 2014 us=706069 mode = 1
Tue Apr 15 08:06:40 2014 us=706108 persist_config = DISABLED
Tue Apr 15 08:06:40 2014 us=706158 persist_mode = 1
Tue Apr 15 08:06:40 2014 us=706196 show_ciphers = DISABLED
Tue Apr 15 08:06:40 2014 us=706232 show_digests = DISABLED
Tue Apr 15 08:06:40 2014 us=706269 show_engines = DISABLED
Tue Apr 15 08:06:40 2014 us=706308 genkey = DISABLED
Tue Apr 15 08:06:40 2014 us=706346 key_pass_file = '[UNDEF]'
Tue Apr 15 08:06:40 2014 us=706391 show_tls_ciphers = DISABLED
Tue Apr 15 08:06:40 2014 us=706434 Connection profiles [default]:
Tue Apr 15 08:06:40 2014 us=706480 proto = udp
Tue Apr 15 08:06:40 2014 us=706518 local = '[UNDEF]'
Tue Apr 15 08:06:40 2014 us=706555 local_port = 1194
Tue Apr 15 08:06:40 2014 us=706610 remote = '[UNDEF]'
Tue Apr 15 08:06:40 2014 us=706654 remote_port = 1194
Tue Apr 15 08:06:40 2014 us=706690 remote_float = DISABLED
Tue Apr 15 08:06:40 2014 us=706727 bind_defined = DISABLED
Tue Apr 15 08:06:40 2014 us=706763 bind_local = ENABLED
Tue Apr 15 08:06:40 2014 us=706802 NOTE: --mute triggered...
Tue Apr 15 08:06:40 2014 us=706869 259 variation(s) on previous 20 message(s) suppressed by --mute
Tue Apr 15 08:06:40 2014 us=706916 OpenVPN 2.3.2 i686-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Sep 12 2013
Tue Apr 15 08:06:40 2014 us=707174 NOTE: when bridging your LAN adapter with the TAP adapter, note that the new bridge adapter will often take on its own IP address that is different from what the LAN adapter was previously set to
Tue Apr 15 08:06:40 2014 us=708823 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Tue Apr 15 08:06:40 2014 us=811395 Diffie-Hellman initialized with 2048 bit key
Tue Apr 15 08:06:40 2014 us=832104 Control Channel Authentication: using 'ta.key' as a OpenVPN static key file
Tue Apr 15 08:06:40 2014 us=847122 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Apr 15 08:06:40 2014 us=847183 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Apr 15 08:06:40 2014 us=847233 TLS-Auth MTU parms [ L:1590 D:166 EF:66 EB:0 ET:0 EL:0 ]
Tue Apr 15 08:06:40 2014 us=847300 Socket Buffers: R=[112640->131072] S=[112640->131072]
Tue Apr 15 08:06:40 2014 us=848630 TUN/TAP device tap0 opened
Tue Apr 15 08:06:40 2014 us=848790 TUN/TAP TX queue length set to 100
Tue Apr 15 08:06:40 2014 us=848999 /etc/openvpn/up.sh br0 eth0 tap0 1500 1590 init
Tue Apr 15 08:06:40 2014 us=879726 Data Channel MTU parms [ L:1590 D:1450 EF:58 EB:135 ET:32 EL:0 AF:3/1 ]
Tue Apr 15 08:06:40 2014 us=882850 GID set to nobody
Tue Apr 15 08:06:40 2014 us=883040 UID set to nobody
Tue Apr 15 08:06:40 2014 us=883124 UDPv4 link local (bound): [undef]
Tue Apr 15 08:06:40 2014 us=883164 UDPv4 link remote: [undef]
Tue Apr 15 08:06:40 2014 us=883227 MULTI: multi_init called, r=256 v=256
Tue Apr 15 08:06:40 2014 us=883453 IFCONFIG POOL: base=10.0.2.151 size=50, ipv6=0
Tue Apr 15 08:06:40 2014 us=885683 ifconfig_pool_read(), in='client1,10.0.2.151', TODO: IPv6
Tue Apr 15 08:06:40 2014 us=885983 succeeded -> ifconfig_pool_set()
Tue Apr 15 08:06:40 2014 us=886076 ifconfig_pool_read(), in='client2,10.0.2.152', TODO: IPv6
Tue Apr 15 08:06:40 2014 us=886225 succeeded -> ifconfig_pool_set()
Tue Apr 15 08:06:40 2014 us=886285 ifconfig_pool_read(), in='client3,10.0.2.153', TODO: IPv6
Tue Apr 15 08:06:40 2014 us=886407 succeeded -> ifconfig_pool_set()
Tue Apr 15 08:06:40 2014 us=886471 ifconfig_pool_read(), in='client4,10.0.2.154', TODO: IPv6
Tue Apr 15 08:06:40 2014 us=886646 succeeded -> ifconfig_pool_set()
Tue Apr 15 08:06:40 2014 us=886732 ifconfig_pool_read(), in='client5,10.0.2.155', TODO: IPv6
Tue Apr 15 08:06:40 2014 us=886847 succeeded -> ifconfig_pool_set()
Tue Apr 15 08:06:40 2014 us=886906 ifconfig_pool_read(), in='client6,10.0.2.156', TODO: IPv6
Tue Apr 15 08:06:40 2014 us=887068 succeeded -> ifconfig_pool_set()
Tue Apr 15 08:06:40 2014 us=887124 ifconfig_pool_read(), in='client7,10.0.2.157', TODO: IPv6
Tue Apr 15 08:06:40 2014 us=887224 succeeded -> ifconfig_pool_set()
Tue Apr 15 08:06:40 2014 us=887271 ifconfig_pool_read(), in='client8,10.0.2.158', TODO: IPv6
Tue Apr 15 08:06:40 2014 us=887360 succeeded -> ifconfig_pool_set()
Tue Apr 15 08:06:40 2014 us=887423 ifconfig_pool_read(), in='client9,10.0.2.159', TODO: IPv6
Tue Apr 15 08:06:40 2014 us=887519 succeeded -> ifconfig_pool_set()
Tue Apr 15 08:06:40 2014 us=887573 ifconfig_pool_read(), in='client10,10.0.2.160', TODO: IPv6
Tue Apr 15 08:06:40 2014 us=887776 succeeded -> ifconfig_pool_set()
Tue Apr 15 08:06:40 2014 us=887841 ifconfig_pool_read(), in='client11,10.0.2.161', TODO: IPv6
Tue Apr 15 08:06:40 2014 us=887948 succeeded -> ifconfig_pool_set()
Tue Apr 15 08:06:40 2014 us=888021 ifconfig_pool_read(), in='client12,10.0.2.162', TODO: IPv6
Tue Apr 15 08:06:40 2014 us=888144 succeeded -> ifconfig_pool_set()
Tue Apr 15 08:06:40 2014 us=888189 ifconfig_pool_read(), in='client13,10.0.2.163', TODO: IPv6
Tue Apr 15 08:06:40 2014 us=888283 succeeded -> ifconfig_pool_set()
Tue Apr 15 08:06:40 2014 us=888328 ifconfig_pool_read(), in='client14,10.0.2.164', TODO: IPv6
Tue Apr 15 08:06:40 2014 us=888447 succeeded -> ifconfig_pool_set()
Tue Apr 15 08:06:40 2014 us=888489 ifconfig_pool_read(), in='client15,10.0.2.165', TODO: IPv6
Tue Apr 15 08:06:40 2014 us=888565 succeeded -> ifconfig_pool_set()
Tue Apr 15 08:06:40 2014 us=888657 ifconfig_pool_read(), in='client16,10.0.2.166', TODO: IPv6
Tue Apr 15 08:06:40 2014 us=888807 succeeded -> ifconfig_pool_set()
Tue Apr 15 08:06:40 2014 us=888916 IFCONFIG POOL LIST
Tue Apr 15 08:06:40 2014 us=888979 client1,10.0.2.151
Tue Apr 15 08:06:40 2014 us=889033 client2,10.0.2.152
Tue Apr 15 08:06:40 2014 us=889070 client3,10.0.2.153
Tue Apr 15 08:06:40 2014 us=889105 client4,10.0.2.154
Tue Apr 15 08:06:40 2014 us=889152 client5,10.0.2.155
Tue Apr 15 08:06:40 2014 us=889204 client6,10.0.2.156
Tue Apr 15 08:06:40 2014 us=889245 client7,10.0.2.157
Tue Apr 15 08:06:40 2014 us=889287 client8,10.0.2.158
Tue Apr 15 08:06:40 2014 us=889329 client9,10.0.2.159
Tue Apr 15 08:06:40 2014 us=889381 client10,10.0.2.160
Tue Apr 15 08:06:40 2014 us=889433 client11,10.0.2.161
Tue Apr 15 08:06:40 2014 us=889491 client12,10.0.2.162
Tue Apr 15 08:06:40 2014 us=889539 client13,10.0.2.163
Tue Apr 15 08:06:40 2014 us=896686 client14,10.0.2.164
Tue Apr 15 08:06:40 2014 us=896775 client15,10.0.2.165
Tue Apr 15 08:06:40 2014 us=896810 client16,10.0.2.166
Tue Apr 15 08:06:40 2014 us=896972 Initialization Sequence Completed
Tue Apr 15 08:06:50 2014 us=565708 MULTI: multi_create_instance called
Tue Apr 15 08:06:50 2014 us=566750 72.135.8.130:55745 Re-using SSL/TLS context
Tue Apr 15 08:06:50 2014 us=566885 72.135.8.130:55745 LZO compression initialized
Tue Apr 15 08:06:50 2014 us=567377 72.135.8.130:55745 Control Channel MTU parms [ L:1590 D:166 EF:66 EB:0 ET:0 EL:0 ]
Tue Apr 15 08:06:50 2014 us=567470 72.135.8.130:55745 Data Channel MTU parms [ L:1590 D:1450 EF:58 EB:135 ET:32 EL:0 AF:3/1 ]
Tue Apr 15 08:06:50 2014 us=567578 72.135.8.130:55745 Local Options String: 'V4,dev-type tap,link-mtu 1590,tun-mtu 1532,proto UDPv4,comp-lzo,keydir 0,cipher AES-256-CBC,auth SHA1,keysize 256,tls-auth,key-method 2,tls-server'
Tue Apr 15 08:06:50 2014 us=567625 72.135.8.130:55745 Expected Remote Options String: 'V4,dev-type tap,link-mtu 1590,tun-mtu 1532,proto UDPv4,comp-lzo,keydir 1,cipher AES-256-CBC,auth SHA1,keysize 256,tls-auth,key-method 2,tls-client'
Tue Apr 15 08:06:50 2014 us=567708 72.135.8.130:55745 Local Options hash (VER=V4): '44bd8b5e'
Tue Apr 15 08:06:50 2014 us=567780 72.135.8.130:55745 Expected Remote Options hash (VER=V4): '48527533'
Tue Apr 15 08:06:50 2014 us=571383 72.135.8.130:55745 UDPv4 READ [42] from [AF_INET]72.135.8.130:55745: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #5 ] [ ] pid=0 DATA len=0
Tue Apr 15 08:06:50 2014 us=571465 72.135.8.130:55745 TLS: Initial packet from [AF_INET]72.135.8.130:55745, sid=f9d2e050 be484de3
Tue Apr 15 08:06:50 2014 us=571595 72.135.8.130:55745 UDPv4 WRITE [54] to [AF_INET]72.135.8.130:55745: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 pid=[ #1 ] [ 0 ] pid=0 DATA len=0
Tue Apr 15 08:06:50 2014 us=658963 72.135.8.130:55745 UDPv4 READ [50] from [AF_INET]72.135.8.130:55745: P_ACK_V1 kid=0 pid=[ #6 ] [ 0 ]
Tue Apr 15 08:06:50 2014 us=661767 72.135.8.130:55745 UDPv4 READ [142] from [AF_INET]72.135.8.130:55745: P_CONTROL_V1 kid=0 pid=[ #7 ] [ ] pid=1 DATA len=100
Tue Apr 15 08:06:50 2014 us=662015 72.135.8.130:55745 UDPv4 WRITE [50] to [AF_INET]72.135.8.130:55745: P_ACK_V1 kid=0 pid=[ #2 ] [ 1 ]
Tue Apr 15 08:06:50 2014 us=663717 72.135.8.130:55745 UDPv4 READ [142] from [AF_INET]72.135.8.130:55745: P_CONTROL_V1 kid=0 pid=[ #8 ] [ ] pid=2 DATA len=100
Tue Apr 15 08:06:50 2014 us=663965 72.135.8.130:55745 UDPv4 WRITE [50] to [AF_INET]72.135.8.130:55745: P_ACK_V1 kid=0 pid=[ #3 ] [ 2 ]
Tue Apr 15 08:06:50 2014 us=665403 72.135.8.130:55745 UDPv4 READ [69] from [AF_INET]72.135.8.130:55745: P_CONTROL_V1 kid=0 pid=[ #9 ] [ ] pid=3 DATA len=27
Tue Apr 15 08:06:50 2014 us=758902 72.135.8.130:55745 UDPv4 WRITE [154] to [AF_INET]72.135.8.130:55745: P_CONTROL_V1 kid=0 pid=[ #4 ] [ 3 ] pid=1 DATA len=100
Tue Apr 15 08:06:50 2014 us=759175 72.135.8.130:55745 UDPv4 WRITE [142] to [AF_INET]72.135.8.130:55745: P_CONTROL_V1 kid=0 pid=[ #5 ] [ ] pid=2 DATA len=100
Tue Apr 15 08:06:50 2014 us=759370 72.135.8.130:55745 UDPv4 WRITE [142] to [AF_INET]72.135.8.130:55745: P_CONTROL_V1 kid=0 pid=[ #6 ] [ ] pid=3 DATA len=100
Tue Apr 15 08:06:50 2014 us=759546 72.135.8.130:55745 UDPv4 WRITE [142] to [AF_INET]72.135.8.130:55745: P_CONTROL_V1 kid=0 pid=[ #7 ] [ ] pid=4 DATA len=100
Tue Apr 15 08:06:50 2014 us=838910 72.135.8.130:55745 UDPv4 READ [50] from [AF_INET]72.135.8.130:55745: P_ACK_V1 kid=0 pid=[ #10 ] [ 1 ]
Tue Apr 15 08:06:50 2014 us=840464 72.135.8.130:55745 UDPv4 WRITE [142] to [AF_INET]72.135.8.130:55745: P_CONTROL_V1 kid=0 pid=[ #8 ] [ ] pid=5 DATA len=100
Tue Apr 15 08:06:50 2014 us=864452 72.135.8.130:55745 UDPv4 READ [50] from [AF_INET]72.135.8.130:55745: P_ACK_V1 kid=0 pid=[ #11 ] [ 2 ]
Tue Apr 15 08:06:50 2014 us=864696 72.135.8.130:55745 UDPv4 WRITE [142] to [AF_INET]72.135.8.130:55745: P_CONTROL_V1 kid=0 pid=[ #9 ] [ ] pid=6 DATA len=100
Tue Apr 15 08:06:50 2014 us=865748 72.135.8.130:55745 UDPv4 READ [50] from [AF_INET]72.135.8.130:55745: P_ACK_V1 kid=0 pid=[ #12 ] [ 3 ]
Tue Apr 15 08:06:50 2014 us=865971 72.135.8.130:55745 UDPv4 WRITE [142] to [AF_INET]72.135.8.130:55745: P_CONTROL_V1 kid=0 pid=[ #10 ] [ ] pid=7 DATA len=100
Tue Apr 15 08:06:50 2014 us=867480 72.135.8.130:55745 UDPv4 READ [50] from [AF_INET]72.135.8.130:55745: P_ACK_V1 kid=0 pid=[ #13 ] [ 4 ]
Tue Apr 15 08:06:50 2014 us=867710 72.135.8.130:55745 UDPv4 WRITE [142] to [AF_INET]72.135.8.130:55745: P_CONTROL_V1 kid=0 pid=[ #11 ] [ ] pid=8 DATA len=100
Tue Apr 15 08:06:50 2014 us=920969 72.135.8.130:55745 UDPv4 READ [50] from [AF_INET]72.135.8.130:55745: P_ACK_V1 kid=0 pid=[ #14 ] [ 5 ]
Tue Apr 15 08:06:50 2014 us=921191 72.135.8.130:55745 NOTE: --mute triggered...
Tue Apr 15 08:06:52 2014 us=87702 72.135.8.130:55745 107 variation(s) on previous 20 message(s) suppressed by --mute
Tue Apr 15 08:06:52 2014 us=88172 72.135.8.130:55745 VERIFY OK: depth=1, C=US, ST=CO, L=Fake, O=fake, CN=vpn.fake.com, name=vpn, emailAddress=admins@fake.com
Tue Apr 15 08:06:52 2014 us=88825 72.135.8.130:55745 VERIFY OK: depth=0, C=US, ST=CO, L=Fake, O=fake, CN=client2, name=client2, emailAddress=client2.test@fake.com
Tue Apr 15 08:06:52 2014 us=88967 72.135.8.130:55745 UDPv4 WRITE [50] to [AF_INET]72.135.8.130:55745: P_ACK_V1 kid=0 pid=[ #64 ] [ 28 ]
Tue Apr 15 08:06:52 2014 us=91987 72.135.8.130:55745 UDPv4 READ [142] from [AF_INET]72.135.8.130:55745: P_CONTROL_V1 kid=0 pid=[ #70 ] [ ] pid=29 DATA len=100
Tue Apr 15 08:06:52 2014 us=92094 72.135.8.130:55745 UDPv4 WRITE [50] to [AF_INET]72.135.8.130:55745: P_ACK_V1 kid=0 pid=[ #65 ] [ 29 ]
Tue Apr 15 08:06:52 2014 us=96819 72.135.8.130:55745 UDPv4 READ [142] from [AF_INET]72.135.8.130:55745: P_CONTROL_V1 kid=0 pid=[ #71 ] [ ] pid=30 DATA len=100
Tue Apr 15 08:06:52 2014 us=96926 72.135.8.130:55745 UDPv4 WRITE [50] to [AF_INET]72.135.8.130:55745: P_ACK_V1 kid=0 pid=[ #66 ] [ 30 ]
Tue Apr 15 08:06:52 2014 us=98971 72.135.8.130:55745 UDPv4 READ [142] from [AF_INET]72.135.8.130:55745: P_CONTROL_V1 kid=0 pid=[ #72 ] [ ] pid=31 DATA len=100
Tue Apr 15 08:06:52 2014 us=146617 72.135.8.130:55745 UDPv4 WRITE [50] to [AF_INET]72.135.8.130:55745: P_ACK_V1 kid=0 pid=[ #67 ] [ 31 ]
Tue Apr 15 08:06:52 2014 us=172281 72.135.8.130:55745 UDPv4 READ [142] from [AF_INET]72.135.8.130:55745: P_CONTROL_V1 kid=0 pid=[ #73 ] [ ] pid=32 DATA len=100
Tue Apr 15 08:06:52 2014 us=172382 72.135.8.130:55745 UDPv4 WRITE [50] to [AF_INET]72.135.8.130:55745: P_ACK_V1 kid=0 pid=[ #68 ] [ 32 ]
Tue Apr 15 08:06:52 2014 us=174045 72.135.8.130:55745 UDPv4 READ [142] from [AF_INET]72.135.8.130:55745: P_CONTROL_V1 kid=0 pid=[ #74 ] [ ] pid=33 DATA len=100
Tue Apr 15 08:06:52 2014 us=174139 72.135.8.130:55745 UDPv4 WRITE [50] to [AF_INET]72.135.8.130:55745: P_ACK_V1 kid=0 pid=[ #69 ] [ 33 ]
Tue Apr 15 08:06:52 2014 us=179219 72.135.8.130:55745 UDPv4 READ [113] from [AF_INET]72.135.8.130:55745: P_CONTROL_V1 kid=0 pid=[ #75 ] [ ] pid=34 DATA len=71
Tue Apr 15 08:06:52 2014 us=180719 72.135.8.130:55745 UDPv4 WRITE [154] to [AF_INET]72.135.8.130:55745: P_CONTROL_V1 kid=0 pid=[ #70 ] [ 34 ] pid=37 DATA len=100
Tue Apr 15 08:06:52 2014 us=180885 72.135.8.130:55745 UDPv4 WRITE [142] to [AF_INET]72.135.8.130:55745: P_CONTROL_V1 kid=0 pid=[ #71 ] [ ] pid=38 DATA len=100
Tue Apr 15 08:06:52 2014 us=180972 72.135.8.130:55745 UDPv4 WRITE [142] to [AF_INET]72.135.8.130:55745: P_CONTROL_V1 kid=0 pid=[ #72 ] [ ] pid=39 DATA len=100
Tue Apr 15 08:06:52 2014 us=181049 72.135.8.130:55745 UDPv4 WRITE [142] to [AF_INET]72.135.8.130:55745: P_CONTROL_V1 kid=0 pid=[ #73 ] [ ] pid=40 DATA len=100
Tue Apr 15 08:06:52 2014 us=265515 72.135.8.130:55745 UDPv4 READ [50] from [AF_INET]72.135.8.130:55745: P_ACK_V1 kid=0 pid=[ #76 ] [ 37 ]
Tue Apr 15 08:06:52 2014 us=265597 72.135.8.130:55745 UDPv4 WRITE [142] to [AF_INET]72.135.8.130:55745: P_CONTROL_V1 kid=0 pid=[ #74 ] [ ] pid=41 DATA len=100
Tue Apr 15 08:06:52 2014 us=268100 72.135.8.130:55745 UDPv4 READ [50] from [AF_INET]72.135.8.130:55745: P_ACK_V1 kid=0 pid=[ #77 ] [ 38 ]
Tue Apr 15 08:06:52 2014 us=268176 72.135.8.130:55745 UDPv4 WRITE [142] to [AF_INET]72.135.8.130:55745: P_CONTROL_V1 kid=0 pid=[ #75 ] [ ] pid=42 DATA len=100
Tue Apr 15 08:06:52 2014 us=269313 72.135.8.130:55745 NOTE: --mute triggered...
Tue Apr 15 08:06:52 2014 us=528810 72.135.8.130:55745 28 variation(s) on previous 20 message(s) suppressed by --mute
Tue Apr 15 08:06:52 2014 us=528883 72.135.8.130:55745 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Tue Apr 15 08:06:52 2014 us=528913 72.135.8.130:55745 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Apr 15 08:06:52 2014 us=528941 72.135.8.130:55745 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Tue Apr 15 08:06:52 2014 us=528970 72.135.8.130:55745 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Apr 15 08:06:52 2014 us=529068 72.135.8.130:55745 UDPv4 WRITE [154] to [AF_INET]72.135.8.130:55745: P_CONTROL_V1 kid=0 pid=[ #88 ] [ 38 ] pid=52 DATA len=100
Tue Apr 15 08:06:52 2014 us=529164 72.135.8.130:55745 UDPv4 WRITE [142] to [AF_INET]72.135.8.130:55745: P_CONTROL_V1 kid=0 pid=[ #89 ] [ ] pid=53 DATA len=100
Tue Apr 15 08:06:52 2014 us=529241 72.135.8.130:55745 UDPv4 WRITE [140] to [AF_INET]72.135.8.130:55745: P_CONTROL_V1 kid=0 pid=[ #90 ] [ ] pid=54 DATA len=98
Tue Apr 15 08:06:52 2014 us=613160 72.135.8.130:55745 UDPv4 READ [50] from [AF_INET]72.135.8.130:55745: P_ACK_V1 kid=0 pid=[ #94 ] [ 52 ]
Tue Apr 15 08:06:52 2014 us=614356 72.135.8.130:55745 UDPv4 READ [50] from [AF_INET]72.135.8.130:55745: P_ACK_V1 kid=0 pid=[ #95 ] [ 53 ]
Tue Apr 15 08:06:52 2014 us=615699 72.135.8.130:55745 UDPv4 READ [50] from [AF_INET]72.135.8.130:55745: P_ACK_V1 kid=0 pid=[ #96 ] [ 54 ]
Tue Apr 15 08:06:52 2014 us=615762 72.135.8.130:55745 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Tue Apr 15 08:06:52 2014 us=615808 72.135.8.130:55745 [client2] Peer Connection Initiated with [AF_INET]72.135.8.130:55745
Tue Apr 15 08:06:52 2014 us=615907 client2/72.135.8.130:55745 MULTI_sva: pool returned IPv4=10.0.2.152, IPv6=(Not enabled)
Tue Apr 15 08:06:54 2014 us=341178 client2/72.135.8.130:55745 UDPv4 WRITE [117] to [AF_INET]72.135.8.130:55745: P_DATA_V1 kid=0 DATA len=116
Tue Apr 15 08:06:54 2014 us=425420 client2/72.135.8.130:55745 UDPv4 READ [132] from [AF_INET]72.135.8.130:55745: P_CONTROL_V1 kid=0 pid=[ #97 ] [ ] pid=39 DATA len=90
Tue Apr 15 08:06:54 2014 us=425568 client2/72.135.8.130:55745 PUSH: Received control message: 'PUSH_REQUEST'
Tue Apr 15 08:06:54 2014 us=425598 client2/72.135.8.130:55745 send_push_reply(): safe_cap=940
Tue Apr 15 08:06:54 2014 us=425666 client2/72.135.8.130:55745 SENT CONTROL [client2]: 'PUSH_REPLY,dhcp-option DNS 10.0.0.191,route-gateway 10.0.1.202,ping 10,ping-restart 120,ifconfig 10.0.2.152 255.255.252.0' (status=1)
Tue Apr 15 08:06:54 2014 us=425711 client2/72.135.8.130:55745 UDPv4 WRITE [50] to [AF_INET]72.135.8.130:55745: P_ACK_V1 kid=0 pid=[ #91 ] [ 39 ]
Tue Apr 15 08:06:54 2014 us=425806 client2/72.135.8.130:55745 UDPv4 WRITE [142] to [AF_INET]72.135.8.130:55745: P_CONTROL_V1 kid=0 pid=[ #92 ] [ ] pid=55 DATA len=100
Tue Apr 15 08:06:54 2014 us=425916 client2/72.135.8.130:55745 UDPv4 WRITE [128] to [AF_INET]72.135.8.130:55745: P_CONTROL_V1 kid=0 pid=[ #93 ] [ ] pid=56 DATA len=86
Tue Apr 15 08:06:54 2014 us=504644 client2/72.135.8.130:55745 UDPv4 READ [50] from [AF_INET]72.135.8.130:55745: P_ACK_V1 kid=0 pid=[ #98 ] [ 55 ]
Tue Apr 15 08:06:54 2014 us=526595 client2/72.135.8.130:55745 UDPv4 READ [50] from [AF_INET]72.135.8.130:55745: P_ACK_V1 kid=0 pid=[ #99 ] [ 56 ]
Tue Apr 15 08:06:54 2014 us=549861 client2/72.135.8.130:55745 UDPv4 READ [133] from [AF_INET]72.135.8.130:55745: P_DATA_V1 kid=0 DATA len=132
Tue Apr 15 08:06:54 2014 us=549938 client2/72.135.8.130:55745 MULTI: Learn: 00:ff:06:75:43:75 -> client2/72.135.8.130:55745
Tue Apr 15 08:06:54 2014 us=549983 client2/72.135.8.130:55745 TUN WRITE [90]
Tue Apr 15 08:06:54 2014 us=552208 client2/72.135.8.130:55745 UDPv4 READ [133] from [AF_INET]72.135.8.130:55745: P_DATA_V1 kid=0 DATA len=132
Tue Apr 15 08:06:54 2014 us=552274 client2/72.135.8.130:55745 TUN WRITE [85]
Tue Apr 15 08:06:54 2014 us=683746 client2/72.135.8.130:55745 UDPv4 READ [133] from [AF_INET]72.135.8.130:55745: P_DATA_V1 kid=0 DATA len=132
Tue Apr 15 08:06:54 2014 us=683884 client2/72.135.8.130:55745 TUN WRITE [90]
Tue Apr 15 08:06:54 2014 us=686261 client2/72.135.8.130:55745 UDPv4 READ [101] from [AF_INET]72.135.8.130:55745: P_DATA_V1 kid=0 DATA len=100
Tue Apr 15 08:06:54 2014 us=686326 client2/72.135.8.130:55745 TUN WRITE [54]
Tue Apr 15 08:06:54 2014 us=690132 client2/72.135.8.130:55745 UDPv4 READ [85] from [AF_INET]72.135.8.130:55745: P_DATA_V1 kid=0 DATA len=84
Tue Apr 15 08:06:54 2014 us=690204 client2/72.135.8.130:55745 TUN WRITE [42]
Tue Apr 15 08:06:54 2014 us=692256 client2/72.135.8.130:55745 UDPv4 READ [85] from [AF_INET]72.135.8.130:55745: P_DATA_V1 kid=0 DATA len=84
Tue Apr 15 08:06:54 2014 us=692324 client2/72.135.8.130:55745 TUN WRITE [42]
Tue Apr 15 08:06:54 2014 us=694079 client2/72.135.8.130:55745 UDPv4 READ [117] from [AF_INET]72.135.8.130:55745: P_DATA_V1 kid=0 DATA len=116
Tue Apr 15 08:06:54 2014 us=694145 client2/72.135.8.130:55745 TUN WRITE [62]
Tue Apr 15 08:06:54 2014 us=696682 client2/72.135.8.130:55745 UDPv4 READ [133] from [AF_INET]72.135.8.130:55745: P_DATA_V1 kid=0 DATA len=132
Tue Apr 15 08:06:54 2014 us=696751 client2/72.135.8.130:55745 TUN WRITE [78]
Tue Apr 15 08:06:54 2014 us=698734 client2/72.135.8.130:55745 UDPv4 READ [117] from [AF_INET]72.135.8.130:55745: P_DATA_V1 kid=0 DATA len=116
Tue Apr 15 08:06:54 2014 us=698801 client2/72.135.8.130:55745 TUN WRITE [70]
Tue Apr 15 08:06:54 2014 us=700862 client2/72.135.8.130:55745 UDPv4 READ [149] from [AF_INET]72.135.8.130:55745: P_DATA_V1 kid=0 DATA len=148
Tue Apr 15 08:06:54 2014 us=700949 client2/72.135.8.130:55745 TUN WRITE [130]
Tue Apr 15 08:06:54 2014 us=703236 client2/72.135.8.130:55745 UDPv4 READ [149] from [AF_INET]72.135.8.130:55745: P_DATA_V1 kid=0 DATA len=148
Tue Apr 15 08:06:54 2014 us=703305 client2/72.135.8.130:55745 NOTE: --mute triggered...
Tue Apr 15 09:06:53 2014 us=137308 client2/72.135.8.130:55745 17816 variation(s) on previous 20 message(s) suppressed by --mute
Tue Apr 15 09:06:53 2014 us=137412 client2/72.135.8.130:55745 VERIFY OK: depth=1, C=US, ST=CO, L=Fake, O=fake, CN=vpn.fake.com, name=vpn, emailAddress=admins@fake.com
Tue Apr 15 09:06:53 2014 us=138061 client2/72.135.8.130:55745 VERIFY OK: depth=0, C=US, ST=CO, L=Fake, O=fake, CN=client2, name=client2, emailAddress=client2.test@fake.com
Tue Apr 15 09:06:53 2014 us=138181 client2/72.135.8.130:55745 UDPv4 WRITE [50] to [AF_INET]72.135.8.130:55745: P_ACK_V1 kid=1 pid=[ #157 ] [ 28 ]
Tue Apr 15 09:06:53 2014 us=141323 client2/72.135.8.130:55745 UDPv4 READ [142] from [AF_INET]72.135.8.130:55745: P_CONTROL_V1 kid=1 pid=[ #165 ] [ ] pid=29 DATA len=100
Tue Apr 15 09:06:53 2014 us=141430 client2/72.135.8.130:55745 UDPv4 WRITE [50] to [AF_INET]72.135.8.130:55745: P_ACK_V1 kid=1 pid=[ #158 ] [ 29 ]

Last 30 lines:

Tue Apr 15 15:32:09 2014 us=305435 client16/72.135.8.130:53674 UDPv4 WRITE [197] to [AF_INET]72.135.8.130:53674: P_DATA_V1 kid=0 DATA len=196
Tue Apr 15 15:32:09 2014 us=305529 client2/72.135.8.130:50187 UDPv4 WRITE [197] to [AF_INET]72.135.8.130:50187: P_DATA_V1 kid=2 DATA len=196
Tue Apr 15 15:32:10 2014 us=604543 client16/72.135.8.130:53674 UDPv4 READ [325] from [AF_INET]72.135.8.130:53674: P_DATA_V1 kid=0 DATA len=324
Tue Apr 15 15:32:10 2014 us=604713 client16/72.135.8.130:53674 NOTE: --mute triggered...
Tue Apr 15 15:40:11 2014 us=293920 client2/72.135.8.130:50187 5744 variation(s) on previous 20 message(s) suppressed by --mute
Tue Apr 15 15:40:11 2014 us=294019 client2/72.135.8.130:50187 [client2] Inactivity timeout (--ping-restart), restarting
Tue Apr 15 15:40:11 2014 us=294048 client2/72.135.8.130:50187 SIGUSR1[soft,ping-restart] received, client-instance restarting
Tue Apr 15 15:40:11 2014 us=352228 client16/72.135.8.130:53674 UDPv4 WRITE [197] to [AF_INET]72.135.8.130:53674: P_DATA_V1 kid=0 DATA len=196
Tue Apr 15 15:40:11 2014 us=407818 client16/72.135.8.130:53674 UDPv4 WRITE [117] to [AF_INET]72.135.8.130:53674: P_DATA_V1 kid=0 DATA len=116
Tue Apr 15 15:40:11 2014 us=907866 client16/72.135.8.130:53674 UDPv4 WRITE [117] to [AF_INET]72.135.8.130:53674: P_DATA_V1 kid=0 DATA len=116
Tue Apr 15 15:40:12 2014 us=626666 client16/72.135.8.130:53674 UDPv4 WRITE [117] to [AF_INET]72.135.8.130:53674: P_DATA_V1 kid=0 DATA len=116
Tue Apr 15 15:40:12 2014 us=627676 client16/72.135.8.130:53674 UDPv4 WRITE [117] to [AF_INET]72.135.8.130:53674: P_DATA_V1 kid=0 DATA len=116
Tue Apr 15 15:40:12 2014 us=722448 client16/72.135.8.130:53674 UDPv4 WRITE [117] to [AF_INET]72.135.8.130:53674: P_DATA_V1 kid=0 DATA len=116
Tue Apr 15 15:40:12 2014 us=733842 client16/72.135.8.130:53674 UDPv4 WRITE [117] to [AF_INET]72.135.8.130:53674: P_DATA_V1 kid=0 DATA len=116
Tue Apr 15 15:40:12 2014 us=733939 client16/72.135.8.130:53674 UDPv4 WRITE [117] to [AF_INET]72.135.8.130:53674: P_DATA_V1 kid=0 DATA len=116
Tue Apr 15 15:40:12 2014 us=774816 client16/72.135.8.130:53674 UDPv4 WRITE [229] to [AF_INET]72.135.8.130:53674: P_DATA_V1 kid=0 DATA len=228
Tue Apr 15 15:40:12 2014 us=776841 client16/72.135.8.130:53674 UDPv4 WRITE [117] to [AF_INET]72.135.8.130:53674: P_DATA_V1 kid=0 DATA len=116
Tue Apr 15 15:40:12 2014 us=923529 client16/72.135.8.130:53674 UDPv4 WRITE [117] to [AF_INET]72.135.8.130:53674: P_DATA_V1 kid=0 DATA len=116
Tue Apr 15 15:40:13 2014 us=249077 client16/72.135.8.130:53674 UDPv4 WRITE [197] to [AF_INET]72.135.8.130:53674: P_DATA_V1 kid=0 DATA len=196
Tue Apr 15 15:40:13 2014 us=563208 client16/72.135.8.130:53674 UDPv4 WRITE [229] to [AF_INET]72.135.8.130:53674: P_DATA_V1 kid=0 DATA len=228
Tue Apr 15 15:40:13 2014 us=907901 client16/72.135.8.130:53674 UDPv4 WRITE [117] to [AF_INET]72.135.8.130:53674: P_DATA_V1 kid=0 DATA len=116
Tue Apr 15 15:40:13 2014 us=923634 client16/72.135.8.130:53674 UDPv4 WRITE [117] to [AF_INET]72.135.8.130:53674: P_DATA_V1 kid=0 DATA len=116
Tue Apr 15 15:40:14 2014 us=354658 client16/72.135.8.130:53674 UDPv4 WRITE [133] to [AF_INET]72.135.8.130:53674: P_DATA_V1 kid=0 DATA len=132
Tue Apr 15 15:40:14 2014 us=723475 client16/72.135.8.130:53674 UDPv4 WRITE [117] to [AF_INET]72.135.8.130:53674: P_DATA_V1 kid=0 DATA len=116
Tue Apr 15 15:40:14 2014 us=907979 client16/72.135.8.130:53674 UDPv4 WRITE [117] to [AF_INET]72.135.8.130:53674: P_DATA_V1 kid=0 DATA len=116
Tue Apr 15 15:40:14 2014 us=908111 client16/72.135.8.130:53674 UDPv4 WRITE [117] to [AF_INET]72.135.8.130:53674: P_DATA_V1 kid=0 DATA len=116
Tue Apr 15 15:40:15 2014 us=231781 client16/72.135.8.130:53674 UDPv4 WRITE [117] to [AF_INET]72.135.8.130:53674: P_DATA_V1 kid=0 DATA len=116
Tue Apr 15 15:40:15 2014 us=231930 client16/72.135.8.130:53674 NOTE: --mute triggered...
Tue Apr 15 15:42:09 2014 us=693068 client16/72.135.8.130:53674 534 variation(s) on previous 20 message(s) suppressed by --mute
Tue Apr 15 15:42:09 2014 us=693697 client16/72.135.8.130:53674 [client16] Inactivity timeout (--ping-restart), restarting
Tue Apr 15 15:42:09 2014 us=693732 client16/72.135.8.130:53674 SIGUSR1[soft,ping-restart] received, client-instance restarting

-------------------------------------
When the client fails to connect it says that the "TLS key negotiation failed to occur within 60 seconds" so it seems like the port is being closed. I'm rather stumped as to why it works flawlessly all day after a reboot but when I come in the next day it's down. Can anyone think of a reason why it keeps dying after a day?

Thanks!

B00k3r_D3w1tt

Bump, no one has any suggestions?

B00k3r_D3w1tt

I ended up flushing out all the rules in my firewall and replaced them with these, we'll see if this helps:

# Variables
PRIVATE=10.0.0.0/22
LOOP=127.0.0.1

# Delete old iptables rules
iptables -F

# Set default policies
iptables -P OUTPUT ACCEPT
iptables -P INPUT DROP
iptables -P FORWARD DROP

# Prevent external packets from using loopback addr
iptables -A INPUT -i eth1 -s $LOOP -j DROP
iptables -A FORWARD -i eth1 -s $LOOP -j DROP
iptables -A INPUT -i eth1 -d $LOOP -j DROP
iptables -A FORWARD -i eth1 -d $LOOP -j DROP

# Anything coming from the Internet should have a real Internet address
iptables -A FORWARD -i eth1 -s 192.168.0.0/16 -j DROP
iptables -A FORWARD -i eth1 -s 172.16.0.0/12 -j DROP
iptables -A FORWARD -i eth1 -s 10.0.0.0/8 -j DROP
iptables -A INPUT -i eth1 -s 192.168.0.0/16 -j DROP
iptables -A INPUT -i eth1 -s 172.16.0.0/12 -j DROP
iptables -A INPUT -i eth1 -s 10.0.0.0/8 -j DROP

# Block outgoing NetBios
iptables -A FORWARD -p tcp --sport 137:139 -o eth1 -j DROP
iptables -A FORWARD -p udp --sport 137:139 -o eth1 -j DROP
iptables -A OUTPUT -p tcp --sport 137:139 -o eth1 -j DROP
iptables -A OUTPUT -p udp --sport 137:139 -o eth1 -j DROP

# Check source address validity on packets going out to internet
iptables -A FORWARD -s ! $PRIVATE -i eth0 -j DROP

# Allow local loopback
iptables -A INPUT -s $LOOP -j ACCEPT
iptables -A INPUT -d $LOOP -j ACCEPT

# Allow services such as www and ssh (can be disabled)
iptables -A INPUT -p tcp -s $PRIVATE --dport ssh -j ACCEPT

# Allow incoming OpenVPN packets
# Duplicate the line below for each
# OpenVPN tunnel, changing --dport n
# to match the OpenVPN UDP port.
#
# In OpenVPN, the port number is
# controlled by the --port n option.
# If you put this option in the config
# file, you can remove the leading '--'
#
# If you taking the stateful firewall
# approach (see the OpenVPN HOWTO),
# then comment out the line below.

iptables -A INPUT -p udp --dport 1194 -j ACCEPT

# Allow packets from TUN/TAP devices.
# When OpenVPN is run in a secure mode,
# it will authenticate packets prior
# to their arriving on a tun or tap
# interface. Therefore, it is not
# necessary to add any filters here,
# unless you want to restrict the
# type of packets which can flow over
# the tunnel.

iptables -A INPUT -i tap0 -j ACCEPT
iptables -A FORWARD -i tap0 -j ACCEPT

# Allow packets from private subnets
iptables -A INPUT -i eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -j ACCEPT

# Keep state of connections from local machine and private subnets
iptables -A OUTPUT -m state --state NEW -o eth1 -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -m state --state NEW -o eth1 -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

# Block null packets
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP

# Reject a syn-flood attack
iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP

# Block XMAS packets, also known as recon packets
iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP

# Allow packets to flow freely over tap0 and br0
iptables -A INPUT -i tap0 -j ACCEPT
iptables -A INPUT -i br0 -j ACCEPT
iptables -A FORWARD -i br0 -j ACCEPT

# Save iptables
service iptables save

# Restart iptables
service iptables restart

B00k3r_D3w1tt

I didn't see that anyone replied, thanks for checking it out for me.

debbie10t wrotePerhaps your client (or server) is changing IP due to ISP DHCP ?

I just checked and the client still has the same IP so while I know they're on DHCP, the ISP isn't reassigning them with much frequency. Also, the server is static.

debbie10t wroteInstead of rebooting have a look at your broken VPN with a packet sniffer (Google: Wireshark) and see what is happening ...

That's a good idea, I'll give it a shot. It's kind of hard to spend much time looking at it while it's down since people are calling me telling me to bring it back up.

B00k3r_D3w1tt

Alright so I sniffed the connection while it was down from an external connection, in other words, I was at home and tried to connect to the vpn while it was down and looked at the traffic. My home computer sent the server a packet and the server simply did not respond. It was as if the server was turned off or the port was closed. I used our other VPN connection and ssh'd to the server I poked around for a bit in the logs and didn't see anything and just left the server down. What's weird is I tried it again the next day and it was working. I didn't reset anything so it somehow fixed itself. I then checked it again this morning and it was down again, I had to reboot this morning since it needs be up on business days. I'm really confused now, I figured once it was down it would stay down but somehow it fixed itself for awhile. Very weird... It seems like it might be something with the firewall but about a week ago I removed all the firewall rules and it still went down so I assumed it wasn't the firewall. I'll have to look at it again some more when it goes down.

B00k3r_D3w1tt

This is what's in my up.sh script:

#!/bin/sh

BR=$1
ETHDEV=$2
TAPDEV=$3

/sbin/ip link set "$TAPDEV" up
/sbin/ip link set "$ETHDEV" promisc on
/usr/sbin/brctl addif $BR $TAPDEV

I haven't been able to spend much time on the problem this week, however, I'm beginning to think that there is something going on with the firewall. I got another chance to take a look at the server while it was down and I ended up just restarting the iptables service which brought the vpn back online. I thought for sure I disabled the firewall over night before and it still went down but perhaps I forgot to save the rules and restart the service so they didn't apply... Anyway, I'm going to take a closer look at my rules and try to figure out which one is causing the problem. I pulled most of the new rules from an openvpn article but these ones:

# Block null packets
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP

# Reject a syn-flood attack
iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP

# Block XMAS packets, also known as recon packets
iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP

I more or less came up with on my own, I didn't think they would be a problem since they only apply to tcp traffic. Maybe I'll just remove them for now and see what happens.

B00k3r_D3w1tt

I probably don't have as good of an understanding of how all the bridging works as you do. That being said there are a couple of things about my setup I would like to fill you in on, perhaps this will shed some more light on the configuration.

-My other OpenVPN server uses the same up.sh script and it works without any problems, although it's on an older version of OpenVPN (2.2.1) and it's not using TLS auth / HMAC firewall
-I did setup the bridge prior to having the OpenVPN service start by doing the following (these are the notes I took when doing the install):

Install bridge-utils
yum install bridge-utils -this was already installed
yum install tunctl

Create and edit /etc/sysconfig/network-scripts/ifcfg-br0:
DEVICE=br0
TYPE=Bridge
IPADDR=10.0.1.202
NETMASK=255.255.252.0
ONBOOT=yes
BOOTPROTO=none
NM_CONTROLLED=no
DELAY=0

Edit /etc/sysconfig/network-scripts/ifcfg-eth0 (the internal adapter)
DEVICE=eth0
TYPE=Ethernet
HWADDR=00:0B:CD:9F:AE:34
BOOTPROTO=none
ONBOOT=yes
NM_CONTROLLED=no
BRIDGE=br0

I'm using the up.sh script to create the tap adapter, it was the only way I could get it to work. Do you know of a better way to get the tap adapter up? Thanks again for the help, I appreciate it.

EDIT: Hold on, before you waste your breath I'm going to read some more of the OpenVPN articles.

B00k3r_D3w1tt

ifconfig:

br0       Link encap:Ethernet  HWaddr 00:0B:CD:9F:AE:34
          inet addr:10.0.1.202  Bcast:10.0.3.255  Mask:255.255.252.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:103279 errors:0 dropped:0 overruns:0 frame:0
          TX packets:147 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:8250222 (7.8 MiB)  TX bytes:18926 (18.4 KiB)

eth0      Link encap:Ethernet  HWaddr 00:0B:CD:9F:AE:34
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:124112 errors:0 dropped:0 overruns:0 frame:0
          TX packets:17088 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:17072490 (16.2 MiB)  TX bytes:2924485 (2.7 MiB)
          Interrupt:20

eth1      Link encap:Ethernet  HWaddr 00:30:4F:3B:E1:4A
          inet addr:56.47.14.12  Bcast:76.56.47.32  Mask:255.255.0.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:19810 errors:0 dropped:0 overruns:0 frame:0
          TX packets:124635 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:4293885 (4.0 MiB)  TX bytes:27667677 (26.3 MiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

route:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
56.47.14.1x1    *               255.255.0.0     U     0      0        0 eth1
10.0.0.0        *               255.255.252.0   U     0      0        0 br0
link-local      *               255.255.0.0     U     1003   0        0 eth1
link-local      *               255.255.0.0     U     1004   0        0 br0
default         76-56-47-32-..  0.0.0.0         UG    0      0        0 eth1

I changed my public ip for security reasons.

B00k3r_D3w1tt

default 76-56-47-32-.. ?

Yea I changed the default gateway to just a random number before I posted it, but it does have the dashes in it. So, just to clarify the first entry under "Destination" is my server's public IP address and the default route is the public (modem) gateway (as opposed to the private (router) gateway), not the server's address. They are in the same block and have the same subnet.

As I do not know the details of your network setup I will just make sure this is not an issue:

--server-bridge gateway netmask pool-start-IP pool-end-IP

where gateway is the default gateway of the server not the server IP (Unless the server is the default gateway for the LAN).

So in my server.conf file this is the line I have

server-bridge 10.0.1.202 255.255.252.0 10.0.2.151 10.0.2.200

are you saying that I need to change 10.0.1.202 (private address of the server) to the public gateway address?

B00k3r_D3w1tt

No .. the first parameter of the server-bridge directive is the default gateway of the LAN to which your bridge belongs.

So, my LAN's default gateway is 10.0.1.1, I should change it to that, correct? I made the change and it's still working after a reboot so maybe that will fix it... I'm going to see if it will crash tonight or not and I'll report back. Thanks again for all the help!

I assume you mean why am I bridging as opposed to routing? I use the VPN to do cifs file sharing so I decided to use bridging since it operates on layer 2.

B00k3r_D3w1tt

The question is this:
To what does your eth0 connect
To what does your eth1 connect

Forgot to answer these, eth0(br0) is my LAN and eth1 is public.

B00k3r_D3w1tt

No dice, it went down again. I'm going to take a good look at my bridge configuration and see if I can avoid using the up.sh script in the server.conf file.

B00k3r_D3w1tt

Alright, here's what I have done, hopefully it works:

-Deleted /etc/sysconfig/network-scripts/ifcfg-br0

-Edited /etc/sysconfig/network-scripts/ifcfg-eth0

DEVICE=eth0
TYPE=Ethernet
HWADDR=00:00:00:00:00(this is a fake mac, I have the real one in the file though)
BOOTPROTO=none
ONBOOT=yes
IPADDR=10.0.1.202
NETMASK=255.255.252.0
NM_CONTROLLED=no

-Commented out script-security2 and up.sh and changed dev tap to dev tap0 in the server.conf file.

-Created 2 files:

/etc/openvpn/bridge/bridge-start:

#!/bin/bash

#################################
# Set up Ethernet bridge on Linux
# Requires: bridge-utils
#################################

# Define Bridge Interface
br="br0"

# Define list of TAP interfaces to be bridged,
# for example tap="tap0 tap1 tap2".
tap="tap0"

# Define physical ethernet interface to be bridged
# with TAP interface(s) above.
eth="eth0"
eth_ip="10.0.1.202"
eth_netmask="255.255.252.0"
eth_broadcast="10.0.3.255"

for t in $tap; do
openvpn --mktun --dev $t
done

brctl addbr $br
brctl addif $br $eth

for t in $tap; do
brctl addif $br $t
done

for t in $tap; do
ifconfig $t 0.0.0.0 promisc up
done

ifconfig $eth 0.0.0.0 promisc up

ifconfig $br $eth_ip netmask $eth_netmask broadcast $eth_broadcast

/etc/openvpn/bridge/bridge-stop:

#!/bin/bash

####################################
# Tear Down Ethernet bridge on Linux
####################################

# Define Bridge Interface
br="br0"

# Define list of TAP interfaces to be bridged together
tap="tap0"

ifconfig $br down
brctl delbr $br

for t in $tap; do
openvpn --rmtun --dev $t
done

-Bring up/down the VPN like this:

The OpenVPN bridge can now be started and stopped using this sequence:

run bridge-start
run openvpn
stop openvpn
run bridge-stop

The VPN is working now, I'll let you know if it dies after a day or not.

B00k3r_D3w1tt

Alright so the VPN went down again and I tried several things to bring it back up:

-Stop openvpn service
-Run the bridge-stop script
-Start openvpn service
-Run the bridge-start service

-Stop openvpn service
-Run the bridge-stop script
-Restart iptables service
-Start openvpn service
-Run the bridge-start service

-Stop openvpn service
-Run the bridge-stop script
-Bring down eth0 and eth1
-Bring up eth0 and eth1
-Restart iptables service
-Start openvpn service
-Run the bridge-start service

None of these worked, but this did:

-Stop openvpn service
-Run the bridge-stop script
-Restart the network service
-Start openvpn service
-Run the bridge-start service

It has to be something to do with the network service... Pretty weird that bringing down and up eth1 and eth0 didn't work but restarting the network service did. I'll continue to poke around the network service and see if I can figure out what's dying on me.

B00k3r_D3w1tt

Yea I did, just realized a huge typo, whooops... this is what I meant to say:

Alright so the VPN went down again and I tried several things to bring it back up:

-Stop openvpn service
-Run the bridge-stop script
-Run the bridge-start script
-Start openvpn service

-Stop openvpn service
-Run the bridge-stop script
-Restart iptables service
-Run the bridge-start script
-Start openvpn service

-Stop openvpn service
-Run the bridge-stop script
-Bring down eth0 and eth1
-Bring up eth0 and eth1
-Restart iptables service
-Run the bridge-start script
-Start openvpn service

None of these worked, but this did:

-Stop openvpn service
-Run the bridge-stop script
-Restart the network service
-Run the bridge-start script
-Start openvpn service

It has to be something to do with the network service... Pretty weird that bringing down and up eth1 and eth0 didn't work but restarting the network service did. I'll continue to poke around the network service and see if I can figure out what's dying on me.

B00k3r_D3w1tt

One thing I did when I set up the server was disable ipv6 by doing the following:

echo “net.ipv6.conf.default.disable_ipv6=1″ >> /etc/sysctl.conf
echo “net.ipv6.conf.all.disable_ipv6 = 1″ >> /etc/sysctl.conf

I'm thinking that might have something to do with it, I just deleted those two lines out of the /etc/sysctl.conf file and rebooted the server. I'll let you know if that resolves the problem.

B00k3r_D3w1tt

So, the VPN died again and I had a chance to poke around some more. This time I noticed that my default route was missing. I figured out something was wrong with the gateway since I could ping address on the modem with the public interface but not a public address (by issuing the command ping -I eth1 www.google.com) I added it back in manually (route add) and everything started working again. It seems like this is the root of the problem. I think it's weird that the default route gets added back in when the network service is restarted but somehow deletes itself after the system is up for a while. I went ahead and checked /etc/sysconfig/network and noticed there was not a gateway. Therefore, I added the gateway address in there and rebooted - just to make sure it didn't conflict with something else. To be honest, I'm new to CentOS and I'm not a Linux networking pro. Hopefully this does the trick, I'll keep updating until I get the issue is resolved so that the next poor soul that has this problem can learn from my shortcomings. Does anyone else know what I can check to ensure my default route doesn't get wiped out after the system is up for a period of time?

B00k3r_D3w1tt

Nah, everything is static.

Check this out, today I tried to log into it and it was down. I then ssh'd to the server and ran this command:

ping -I eth1 www.google.com

(eth1 is the public nic) and bam it started working again. It's like the card is falling asleep or something. Could it be because I'm running the service as 'nobody':

user nobody
group nobody

in my config file?

jjbungles

I had the same problem as you. I am running CentOS.

Check your memory. If you have limited memory you need to have swap memory. I think I put on at least a gigabyte if not more and now I am rock solid stable.

JJ

Check my last posts.

B00k3r_D3w1tt

I have 1.5 gb of ram with a 3 gb swap. I stopped trying to figure out what's going on since more pressing issues came up. Anyway, where I left off was thinking either there is something going on with the NIC that eth1 is using or there is just some dumb centos bug that I'm not aware of. I was going to try and switch the interfaces to see if that makes a difference. If that doesn't work I was going to just install Debian server and give that a shot. My current VPN server is running Linux mint with a similar configuration and that thing is rock solid. It's been up for months now without a single issue.