3. Unable to communicate with http://packages.pfsense.org.

Unable to communicate with http://packages.pfsense.org.

  • M

    At dashboard in version section:

    2.1.3-RELEASE (amd64)
built on Thu May 01 15:52:13 EDT 2014
FreeBSD 8.3-RELEASE-p16

Unable to check for updates.

    DNS server(s)
127.0.0.1
194.204.159.1
194.204.152.34
8.8.8.8
8.8.4.4

    when i go to System -> packages -> Avalible packages I get

    Unable to communicate with http://packages.pfsense.org. Please verify DNS and interface configuration, and that pfSense has functional Internet connectivity.

    Machines behind pfsense works ok.
    Pfsense box can't ping anything what isn't in IP format.

    Ping output:

PING 8.8.4.4 (8.8.4.4): 56 data bytes
64 bytes from 8.8.4.4: icmp_seq=0 ttl=46 time=50.582 ms
64 bytes from 8.8.4.4: icmp_seq=1 ttl=46 time=51.167 ms
64 bytes from 8.8.4.4: icmp_seq=2 ttl=46 time=51.813 ms

    PING www.google.com (173.194.113.80): 56 data bytes

--- www.google.com ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss

    Any ideas ? I really need to install openvpn clinet export package…

    0

  • Nowhere near enough information.  Is this a new install?  Has anything changed recently?

    0
  • M

    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.

    0

  • 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?

    0
  • M

    194.204.159.1 -> working WAN
    194.204.152.34  -> working WAN
    8.8.8.8  -> working WAN
    8.8.4.4  -> working WAN

    I'm not changing things if everything works.

    0
  • D

    @Matchek:

    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.

    0
  • M

    dgcom, my bad i was thinking about dhcp for WANs, that was one of them

    0
  • D

    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?
    0
  • M

    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>

    0
  • D

    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?

    0
  • M

    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

    0
  • D

    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.

    0
  • M

    But why i can ping 8.8.8.8 ?

    0
  • D

    Can you ping/trace 208.123.73.88 from internal host?
    What happens when you do Diagnostics->Traceroute to 208.123.73.88?

    0
  • M

    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=46

    tracert 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

    0
  • D

    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 :)

    0
Log in to reply
 

Products

Services

Support

News

Resources

Company

Our Mission

We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

Subscribe to our Newsletter

Product information, software announcements, and special offers. See our newsletter archive for past announcements.

© Copyright 2002 - 2019 Rubicon Communications, LLC | Privacy Policy