Unstable internet since 2.2.4
-
DNS should have nothing to do with ping times (assuming name resolves to same IP address). Once name is resolved to an IP address DNS is out of the picture.
To see where the slowness may be try a trace route (tracert on a Windows client).
-
does this mean anything? the request timed out on step 2. it seemed fast until step 7.
1 <1 ms <1 ms <1 ms pfSense.localdomain [192.168.1.1]
2 * * * Request timed out.
3 9 ms 9 ms 9 ms rd3st-tge0-13-0-10-1.vc.shawcable.net [64.59.150.85]
4 16 ms 10 ms 14 ms 66.163.72.254
5 14 ms 15 ms 16 ms rc5wt-be5.wa.shawcable.net [66.163.74.158]
6 15 ms 15 ms 13 ms xe-9-1-0.sea22.ip4.gtt.net [77.67.71.73]
7 160 ms 161 ms 161 ms xe-1-3-0.fra29.ip4.gtt.net [141.136.108.17]
8 167 ms 170 ms 168 ms a100-gw.ip4.gtt.net [77.67.66.206]
9 168 ms 171 ms 168 ms 54.239.5.110
10 167 ms 169 ms 167 ms 54.239.5.134
11 168 ms 173 ms 172 ms ec2-54-93-175-114.eu-central-1.compute.amazonaws.com [54.93.175.114]and one to google
Tracing route to google-public-dns-a.google.com [8.8.8.8]
over a maximum of 30 hops:1 <1 ms <1 ms <1 ms pfSense.localdomain [192.168.1.1]
2 * * * Request timed out.
3 12 ms 9 ms 10 ms rd3st-tge0-13-0-10-1.vc.shawcable.net [64.59.150.85]
4 18 ms 17 ms 16 ms 66.163.70.106
5 18 ms 15 ms 16 ms rx0wt-google.wa.shawcable.net [66.163.68.50]
6 14 ms 15 ms 17 ms 74.125.37.95
7 15 ms 15 ms 15 ms 209.85.250.121
8 16 ms 16 ms 16 ms google-public-dns-a.google.com [8.8.8.8] -
No the hop #2 time out is not significant. Just means that router does not respond to pings.
Don't see any of the 400 to 800 ms pings you mentioned in the opening post.That doesn't look too bad really. Here's what it looks like from here for comparison.
Tracing route to ec2-54-93-175-114.eu-central-1.compute.amazonaws.com [54.93.175.114] over a maximum of 30 hops: 1 1 ms <1 ms 1 ms pfSense.localdomain [192.168.2.1] 2 6 ms 5 ms 6 ms static-50-53-160-1.bvtn.or.frontiernet.net [50.53.160.1] 3 6 ms 5 ms 5 ms 50.38.7.201 4 19 ms 37 ms 30 ms ae2---0.cor02.bvtn.or.frontiernet.net [74.40.1.181] 5 20 ms 22 ms 20 ms ae3---0.cor01.plal.ca.frontiernet.net [74.40.1.225] 6 21 ms 48 ms 22 ms ae0---0.cbr01.plal.ca.frontiernet.net [74.40.3.150] 7 21 ms 22 ms 19 ms xe-0.paix.plalca01.us.bb.gin.ntt.net [198.32.176.14] 8 231 ms 232 ms 232 ms ae-15.r01.snjsca04.us.bb.gin.ntt.net [129.250.5.33] 9 22 ms 23 ms 22 ms ae-1.r22.snjsca04.us.bb.gin.ntt.net [129.250.3.26] 10 88 ms 88 ms 112 ms ae-8.r21.chcgil09.us.bb.gin.ntt.net [129.250.5.16] 11 132 ms 142 ms 140 ms ae-0.r20.chcgil09.us.bb.gin.ntt.net [129.250.3.97] 12 89 ms 95 ms 88 ms ae-5.r23.nycmny01.us.bb.gin.ntt.net [129.250.2.167] 13 231 ms 232 ms 235 ms ae-6.r21.frnkge03.de.bb.gin.ntt.net [129.250.3.181] 14 * 229 ms 222 ms ae-1.r02.frnkge03.de.bb.gin.ntt.net [129.250.4.163] 15 169 ms 174 ms 177 ms 212.119.27.174 16 * * * Request timed out. 17 * * * Request timed out. 18 170 ms 170 ms 175 ms 54.239.5.134 19 169 ms 169 ms 169 ms ec2-54-93-175-114.eu-central-1.compute.amazonaws.com [54.93.175.114] Trace complete.Tracing route to google-public-dns-a.google.com [8.8.8.8] over a maximum of 30 hops: 1 1 ms 1 ms <1 ms pfSense.localdomain [192.168.2.1] 2 6 ms 5 ms 5 ms static-50-53-160-1.bvtn.or.frontiernet.net [50.53.160.1] 3 7 ms 7 ms 8 ms 50.38.7.201 4 12 ms 10 ms 12 ms ae2---0.cor02.bvtn.or.frontiernet.net [74.40.1.181] 5 9 ms 10 ms 10 ms ae0---0.cor01.bvtn.or.frontiernet.net [74.40.1.185] 6 10 ms 12 ms 10 ms ae4---0.cor01.sttl.wa.frontiernet.net [74.40.1.221] 7 20 ms 18 ms 15 ms ae0---0.cbr01.sttl.wa.frontiernet.net [74.40.5.122] 8 10 ms 12 ms 11 ms 74.40.26.131 9 10 ms 10 ms 10 ms 72.14.238.181 10 10 ms 10 ms 10 ms 209.85.245.67 11 10 ms 10 ms 10 ms google-public-dns-a.google.com [8.8.8.8] Trace complete. -
Oh and by the way that hop #2 is probably the default gateway. So no wonder apinger was having trouble.
So it was probably detecting and marking the WAN interface as down. That's probably why the VPN was going down.
-
hate to sound like any more of a dumbass but is there a way to fix that?
i did another clean install and now am only using WAN and LAN. I also tried plugging my WAN into the other Intel NIC which gets me a different IP address from my ISP to just test, didn't seem to make a difference.
-
Configure apinger to monitor the next available hop. Or leave apinger disabled.
-
thanks NOYB, i configured it to the 2nd hop and am not getting any errors, thanks for the tip. If it gives me any problems, i will disable it but i kind of like having it on. Going to try to setup OpenVPN client tomorrow to see how it works. Have a good night.
-
got the VPN up and working, seems to be better. Having a few VPN errors though. Not sure if it is totally taking the tunnel down or just reporting. Going to google this a little.
Oct 31 13:20:19 openvpn[53731]: MANAGEMENT: Client disconnected
Oct 31 13:20:19 openvpn[53731]: MANAGEMENT: CMD 'status 2'
Oct 31 13:20:19 openvpn[53731]: MANAGEMENT: CMD 'state 1'
Oct 31 13:20:19 openvpn[53731]: MANAGEMENT: Client connected from /var/etc/openvpn/client1.sock
Oct 31 13:17:24 openvpn[53731]: MANAGEMENT: Client disconnected
Oct 31 13:17:24 openvpn[53731]: MANAGEMENT: CMD 'status 2'
Oct 31 13:17:24 openvpn[53731]: MANAGEMENT: CMD 'state 1'
Oct 31 13:17:24 openvpn[53731]: MANAGEMENT: Client connected from /var/etc/openvpn/client1.sock
Oct 31 13:17:23 openvpn[53731]: MANAGEMENT: Client disconnected
Oct 31 13:17:23 openvpn[53731]: MANAGEMENT: CMD 'status 2'
Oct 31 13:17:23 openvpn[53731]: MANAGEMENT: CMD 'state 1'
Oct 31 13:17:23 openvpn[53731]: MANAGEMENT: Client connected from /var/etc/openvpn/client1.sock
Oct 31 13:17:22 openvpn[53731]: MANAGEMENT: Client disconnected
Oct 31 13:17:22 openvpn[53731]: MANAGEMENT: CMD 'status 2'
Oct 31 13:17:22 openvpn[53731]: MANAGEMENT: CMD 'state 1'
Oct 31 13:17:22 openvpn[53731]: MANAGEMENT: Client connected from /var/etc/openvpn/client1.sock
Oct 31 13:17:14 openvpn[53731]: MANAGEMENT: Client disconnected
Oct 31 13:17:14 openvpn[53731]: MANAGEMENT: CMD 'status 2'
Oct 31 13:17:14 openvpn[53731]: MANAGEMENT: CMD 'state 1'
Oct 31 13:17:14 openvpn[53731]: MANAGEMENT: Client connected from /var/etc/openvpn/client1.sock
Oct 31 13:16:43 openvpn[53731]: MANAGEMENT: Client disconnected
Oct 31 13:16:43 openvpn[53731]: MANAGEMENT: CMD 'status 2'
Oct 31 13:16:43 openvpn[53731]: MANAGEMENT: CMD 'state 1' -
hey guys, VPN is up and down like crazy.. here are the logs.. frustrating.. the rest of the network stuff seems good now, this seems like it is the only outstanding problem. Switching next weekend from 30mb cable to 100mb ADSL, can't wait. any ideas?
Nov 1 10:31:14 php-fpm[3124]: /rc.start_packages: Restarting/Starting all packages.
Nov 1 10:31:13 check_reload_status: Starting packages
Nov 1 10:31:13 php-fpm[3124]: /rc.newwanip: pfSense package system has detected an IP change or dynamic WAN reconnection - 10.4.5.207 -> 10.4.14.212 - Restarting packages.
Nov 1 10:31:11 php-fpm[3124]: /rc.newwanip: Creating rrd update script
Nov 1 10:31:07 php-fpm[3124]: /rc.newwanip: IP has changed, killing states on former IP 10.4.5.207.
Nov 1 10:31:07 php-fpm[3124]: /rc.newwanip: rc.newwanip: on (IP address: 10.4.14.212) (interface: AIRVPN_WAN[opt1]) (real interface: ovpnc1).
Nov 1 10:31:07 php-fpm[3124]: /rc.newwanip: rc.newwanip: Info: starting on ovpnc1.
Nov 1 10:31:06 check_reload_status: rc.newwanip starting ovpnc1
Nov 1 10:31:06 kernel: ovpnc1: link state changed to UP
Nov 1 10:31:05 check_reload_status: Reloading filter
Nov 1 10:31:05 kernel: ovpnc1: link state changed to DOWN
Nov 1 09:33:44 php-fpm[58963]: /rc.start_packages: Restarting/Starting all packages.
Nov 1 09:33:43 check_reload_status: Starting packages
Nov 1 09:33:43 php-fpm[58963]: /rc.newwanip: pfSense package system has detected an IP change or dynamic WAN reconnection - 10.4.1.211 -> 10.4.5.207 - Restarting packages.
Nov 1 09:33:41 php-fpm[58963]: /rc.newwanip: Creating rrd update script
Nov 1 09:33:37 php-fpm[58963]: /rc.newwanip: IP has changed, killing states on former IP 10.4.1.211.
Nov 1 09:33:37 php-fpm[58963]: /rc.newwanip: rc.newwanip: on (IP address: 10.4.5.207) (interface: AIRVPN_WAN[opt1]) (real interface: ovpnc1).
Nov 1 09:33:37 php-fpm[58963]: /rc.newwanip: rc.newwanip: Info: starting on ovpnc1.
Nov 1 09:33:36 check_reload_status: rc.newwanip starting ovpnc1
Nov 1 09:33:36 kernel: ovpnc1: link state changed to UP
Nov 1 09:33:35 check_reload_status: Reloading filter
Nov 1 09:33:35 kernel: ovpnc1: link state changed to DOWN
Nov 1 09:14:58 php-fpm[24903]: /rc.start_packages: Restarting/Starting all packages.
Nov 1 09:14:57 check_reload_status: Starting packages
Nov 1 09:14:57 php-fpm[24903]: /rc.newwanip: pfSense package system has detected an IP change or dynamic WAN reconnection - 10.4.7.147 -> 10.4.1.211 - Restarting packages.
Nov 1 09:14:55 php-fpm[24903]: /rc.newwanip: Creating rrd update script
Nov 1 09:14:51 php-fpm[24903]: /rc.newwanip: IP has changed, killing states on former IP 10.4.7.147.
Nov 1 09:14:51 php-fpm[24903]: /rc.newwanip: rc.newwanip: on (IP address: 10.4.1.211) (interface: AIRVPN_WAN[opt1]) (real interface: ovpnc1).
Nov 1 09:14:51 php-fpm[24903]: /rc.newwanip: rc.newwanip: Info: starting on ovpnc1.
Nov 1 09:14:50 check_reload_status: rc.newwanip starting ovpnc1
Nov 1 09:14:50 kernel: ovpnc1: link state changed to UP
Nov 1 09:14:49 check_reload_status: Reloading filter
Nov 1 09:14:49 kernel: ovpnc1: link state changed to DOWN
Nov 1 08:49:53 php-fpm[88638]: /rc.start_packages: Restarting/Starting all packages.
Nov 1 08:49:52 check_reload_status: Starting packages
Nov 1 08:49:52 php-fpm[88638]: /rc.newwanip: pfSense package system has detected an IP change or dynamic WAN reconnection - 10.4.21.60 -> 10.4.7.147 - Restarting packages.
Nov 1 08:49:50 php-fpm[88638]: /rc.newwanip: Creating rrd update script
Nov 1 08:49:46 php-fpm[88638]: /rc.newwanip: IP has changed, killing states on former IP 10.4.21.60.
Nov 1 08:49:46 php-fpm[88638]: /rc.newwanip: rc.newwanip: on (IP address: 10.4.7.147) (interface: AIRVPN_WAN[opt1]) (real interface: ovpnc1).
Nov 1 08:49:46 php-fpm[88638]: /rc.newwanip: rc.newwanip: Info: starting on ovpnc1.
Nov 1 08:49:45 check_reload_status: rc.newwanip starting ovpnc1
Nov 1 08:49:45 kernel: ovpnc1: link state changed to UP
Nov 1 08:49:44 kernel: ovpnc1: link state changed to DOWN
Nov 1 08:20:24 syslogd: kernel boot file is /boot/kernel/kernel -
Try disabling gateway monitoring for both VPN and WAN in System>routing. Openvpn by itself is capable of detecting and reconnecting if the vpn connection is broken.
-
i have all monitoring turned off on the gateways.. just having tons of OpenVPN errors and disconnecting.
-
It happens at 09:14:49, 09:33:35, 10:31:05. Check other logs like gateway, openvpn etc to see what's happening at these times…or probably before these times.
It could easily be that you haven't added custom options from airvpn config into the ovpn client setting's advanced box, like i think once I added mssfix from the vpn's config files, and BAM it was stable. -
This is what is in my advance box, I'm pretty sure you are right though, it is probably something in here:
remote-cert-tls server;comp-lzo no;verb 4;explicit-exit-notify 5;key-direction 1;auth SHA1;keysize 256;key-method 2;tls-cipher TLS-DHE-RSA-WITH-AES-256-CBC-SHA;
I just updated to 60 internet today, clearing all my logs and see what I get, pretty sure it will be the exact same. Nice though, going through the tunnel I get 60, outside the tunnel 70.