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!

Bump, no one has any suggestions?

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

I didn't see that anyone replied, thanks for checking it out for me. [quote="debbie10t"]Perhaps your client (or server) is changing IP due to ISP DHCP ?[/quote] 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. [quote="debbie10t"]Instead of rebooting have a look at your broken VPN with a packet sniffer (Google: Wireshark) and see what is happening ...[/quote] 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.

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.

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.

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): [b]Install bridge-utils[/b] yum install bridge-utils -this was already installed yum install tunctl [b]Create and edit /etc/sysconfig/network-scripts/ifcfg-br0:[/b] DEVICE=br0 TYPE=Bridge IPADDR=10.0.1.202 NETMASK=255.255.252.0 ONBOOT=yes BOOTPROTO=none NM_CONTROLLED=no DELAY=0 [b]Edit /etc/sysconfig/network-scripts/ifcfg-eth0 (the internal adapter)[/b] 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.

[b]ifconfig:[/b] [code]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)[/code] [b]route:[/b] [code]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[/code] [b]I changed my public ip for security reasons.[/b]

[quote]default 76-56-47-32-.. ?[/quote] 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. [quote]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).[/quote] So in my server.conf file this is the line I have [code]server-bridge 10.0.1.202 255.255.252.0 10.0.2.151 10.0.2.200[/code] are you saying that I need to change 10.0.1.202 (private address of the server) to the public gateway address?

[quote]No .. the first parameter of the server-bridge directive is the default gateway of the LAN to which your bridge belongs.[/quote]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.

[quote]The question is this: To what does your eth0 connect To what does your eth1 connect[/quote]Forgot to answer these, eth0(br0) is my LAN and eth1 is public.

[Solved] VPN dies after about a day

B00k3r_D3w1tt

Just to let everyone know where this ended up - I switched to Debian and everything is working fine. I found out that there was a driver issue with the realtek rtl8189 in the centos 6.5 kernel version (2.6) with regard to power management. So the root cause was the adapter was falling asleep and centos 6.5 couldn't wake it up automatically. I tried numerous things to get it working, disabling power management, changing drivers, but ended up changing distros and everything is working now 🙂

« Previous Page