Unable to communicate with http://packages.pfsense.org.
-
It's not new, first version was from 2012 and upgraded ocasionally. Only change is one of WAN's is not providing internet (end of service from internet provider) but link is up device is working w/o providing internet.
Firewall rules olny allow some trafic for vpn and drv monitoring. -
Multiple WANs? Under System - General Setup - DNS servers, you define your DNS servers and which gateway they use. Is it possible that you have them set to use the WAN that is no longer running? Is the non-functional WAN the only difference from when it was last working to now?
-
194.204.159.1 -> working WAN
194.204.152.34 -> working WAN
8.8.8.8 -> working WAN
8.8.4.4 -> working WANI'm not changing things if everything works.
-
192.168.2.254 -> working WAN
Is that correct? That won't work.
Why do you have such mix of DNS servers? Try keeping just Google one's and see if that works.
-
dgcom, my bad i was thinking about dhcp for WANs, that was one of them
-
Ok, I see.
Another thing, which bothers me is that your error says that url is http://packages.pfsense.org - but I think everything was moved to https not that long ago…
What if you go to this page:```
https://<your-pfsense>/pkg_mgr_settings.php</your-pfsense>What if you go to Diagnostics-Command Prompt and execute this:
dig packages.pfsense.org
Does it resolve to the correct IP address?
-
dig packages.pfsense.org
; <<>> DiG 9.6.-ESV-R5-P1 <<>> packages.pfsense.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13961 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;packages.pfsense.org. IN A ;; ANSWER SECTION: packages.pfsense.org. 331 IN A 208.123.73.88 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Jul 25 14:37:03 2014 ;; MSG SIZE rcvd: 54
https://<your-pfsense>/pkg_mgr_settings.php is empty, I tried put in there http://208.123.73.88 but nothing changed.</your-pfsense>
-
Well, then I do not know, sorry. Name resolution seems to be fine.
There were several similar threads about this (like https://forum.pfsense.org/index.php?topic=75265.0). I guess, you went through and checked all possible fixes mentioned?
-
Now I find out that, I cant ping 208.123.73.88…
[2.1.3-RELEASE][maciejdan@zeus....]/home/maciejdan(1): ping http://packages.pfsense.org ping: cannot resolve http://packages.pfsense.org: Unknown host
[2.1.3-RELEASE][maciejdan@zeus....]/home/maciejdan(2): ping http://.pfsense.org ping: cannot resolve http://.pfsense.org: Unknown host
[2.1.3-RELEASE][maciejdan@zeus....]/home/maciejdan(3): ping 208.123.73.88
PING 208.123.73.88 (208.123.73.88): 56 data bytes
^C
--- 208.123.73.88 ping statistics ---
57 packets transmitted, 0 packets received, 100.0% packet loss[2.1.3-RELEASE][maciejdan@zeus....]/home/maciejdan(4): ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: icmp_seq=0 ttl=46 time=50.397 ms 64 bytes from 8.8.8.8: icmp_seq=1 ttl=46 time=50.053 ms ^C --- 8.8.8.8 ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 50.053/50.225/50.397/0.172 ms
[2.1.3-RELEASE][maciejdan@zeus....]/home/maciejdan(5): ping google.com
PING google.com (173.194.112.164): 56 data bytes
^C
--- google.com ping statistics ---
4 packets transmitted, 0 packets received, 100.0% packet loss -
Here you go.
Check all your configured gateways and make sure this goes out through the correct one (important, since you said you had multi-wan before).
Other than that - see if trace route hits something on the way out.
-
But why i can ping 8.8.8.8 ?
-
Can you ping/trace 208.123.73.88 from internal host?
What happens when you do Diagnostics->Traceroute to 208.123.73.88? -
From internal machine```
ping 208.123.73.88
Odpowiedź z 208.123.73.88: bajtów=32 czas=182ms TTL=46
Odpowiedź z 208.123.73.88: bajtów=32 czas=182ms TTL=46tracert 208.123.73.88
1 <1 ms <1 ms 1 ms 192.168.2.254
2 18 ms 16 ms 16 ms war-bg2.idsl.tpnet.pl [83.1.4.30]
3 19 ms 19 ms 18 ms war-r1.tpnet.pl [80.50.157.149]
4 36 ms 35 ms 34 ms bundle-ether2.ffttr3.Frankfurt.opentransit.net [193.251.250.77]
5 53 ms 47 ms 47 ms tengige0-4-0-9.lontr1.London.opentransit.net [193.251.132.186]
6 47 ms 47 ms 47 ms tengige0-9-0-2.lontr1.London.opentransit.net [193.251.128.132]
7 46 ms 88 ms 46 ms abovenet.GW.opentransit.net [193.251.249.202]
8 * 47 ms 46 ms ae10.mpr2.lhr2.uk.above.net [64.125.31.194]
9 122 ms 122 ms 122 ms ae4.cr1.dca2.us.above.net [64.125.20.73]
10 153 ms 153 ms 181 ms ae5.cr1.iah1.us.above.net [64.125.20.186]
11 148 ms 149 ms 148 ms ae1.cr2.iah1.us.above.net [64.125.20.214]
12 153 ms 153 ms 153 ms xe-0-1-0.mpr2.aus1.us.above.net [64.125.27.201]
13 179 ms 179 ms 179 ms ae0.mpr1.aus1.us.above.net [64.125.27.193]
14 167 ms 166 ms 166 ms te-6-1.aus-core-10.above.net [64.125.32.198]
15 162 ms 162 ms 162 ms aus-core-11-v11.corenap.com [198.252.182.149]
16 164 ms 164 ms 164 ms 66.219.34.173
17 161 ms 161 ms 161 ms fw1.pfmechanics.com [208.123.73.3]
18 183 ms 182 ms 182 ms packages.atx.pfmechanics.com [208.123.73.88]diagnostics -> traceroute
1 ANantes-651-1-49-1.w2-0.abo.wanadoo.fr (2.0.0.1) 37.658 ms 39.312 ms 39.905 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *ISSUE found ! problem is openvpn clinet service (2.0.0.1), ok question is how to fix it ? Firewall rules ? with openvpn off
1 192.168.2.254 (192.168.2.254) 0.644 ms 0.417 ms 0.317 ms
2 war-bg2.idsl.tpnet.pl (83.1.4.30) 16.209 ms 16.202 ms 15.696 ms
3 war-r1.tpnet.pl (80.50.157.149) 18.336 ms 17.847 ms 15.942 ms
4 bundle-ether2.ffttr3.Frankfurt.opentransit.net (193.251.250.77) 36.457 ms 36.417 ms 35.452 ms
5 tengige0-4-0-9.lontr1.London.opentransit.net (193.251.132.186) 50.311 ms 47.530 ms 48.043 ms
6 tengige0-9-0-2.lontr1.London.opentransit.net (193.251.128.132) 45.316 ms 47.726 ms 48.170 ms
7 abovenet.GW.opentransit.net (193.251.249.202) 45.292 ms 46.561 ms 44.550 ms
8 ae10.mpr2.lhr2.uk.above.net (64.125.31.194) 45.956 ms * 46.072 ms
9 ae4.cr1.dca2.us.above.net (64.125.20.73) 119.753 ms 122.128 ms 121.492 ms
10 ae5.cr1.iah1.us.above.net (64.125.20.186) 150.995 ms 152.307 ms 150.634 ms
11 ae1.cr2.iah1.us.above.net (64.125.20.214) 163.135 ms 148.732 ms 160.509 ms
12 xe-0-1-0.mpr2.aus1.us.above.net (64.125.27.201) 151.232 ms 152.344 ms 152.977 ms
13 ae0.mpr1.aus1.us.above.net (64.125.27.193) 177.854 ms 178.950 ms 178.674 ms
14 te-6-1.aus-core-10.above.net (64.125.32.198) 164.868 ms 164.337 ms 163.964 ms
15 aus-core-11-v11.corenap.com (198.252.182.149) 161.858 ms 161.817 ms 161.107 ms
16 66.219.34.173 (66.219.34.173) 163.912 ms 163.517 ms 163.233 ms
17 fw1.pfmechanics.com (208.123.73.3) 162.361 ms 159.624 ms 162.241 ms
18 packages.atx.pfmechanics.com (208.123.73.88) 193.918 ms 180.637 ms 180.420 ms -
Well, glad you found what breaks it, but in order to fix it, you have to understand how it breaks it - either by changing routing or by blocking via pf… That I can't probably help you - I do not use OpenVPN.
However - if that is the only thing being blocked, you can always temporarily stop tunnel to check updates as the last resort :)