Solved Cannot access internet in FreeBSD (cannot ping google.com but able to ping 8.8.8.8)

bananaceri

bananaceri

I suspected a few elements due to this issue, as i were saying i was able to ping 8.8.8.8 ,localhost, and my ip (10.82.1.37) but i cannot ping google.com.
I'm configuring a static ip and i am not sure what IP should i put as my dns server. and i am not sure whether my /etc/hosts is being configured correctly.

the main problem is i cannot fetch anything and i can't ping google.com ,it's like i can't access the internet. and my concern is i am not sure my configuration on /etc/hosts and resolv.conf is correct. In addition, i'm configuring on vmware vsphere client (10.82.1.10), the root is with IP (10.82.1.37) . Please help me ,it's my final year project in degree. Every little replies will be appreciated :/
 
Last edited:
What you have configured, looks good. If you are not sure about DNS server, ask the network admin? :) or just try using 8.8.8.8 that you can ping in /etc/resolv.conf.
 
yuripv said:
What you have configured, looks good. If you are not sure about DNS server, ask the network admin? :) or just try using 8.8.8.8 that you can ping in /etc/resolv.conf.
Click to expand...
how to ask the network admin? hm ,i did try to put ' nameserver 8.8.8.8' in the resolv.conf file. but it still doesn't work. thankyou for your reply yuripv..
 
problem.PNG
 
i tried pinging google's IP( 172.217.24.174) ,and it is a success .but not it's domain 'google.com' and i still can't install any packages, it says no address record .
 
What does drill @8.8.8.8 google.com show you?

Also: if you try to ping google.com do you get the error instantaneously or does it take a while to show up?

(edit): What's up with all those suspends? If you continue to press ^Z then you risk turning your sessions into a huge mess. Especially if you have files opened in such sessions, that could cause problems with other updates. Instead of suspending (^Z) kill / stop those processes (^C).
 
bananaceri said:
how to ask the network admin? hm ,i did try to put ' nameserver 8.8.8.8' in the resolv.conf file. but it still doesn't work. thankyou for your reply yuripv..
Click to expand...

sorry ,i realised i was asking a dumb question, bc i was thinking too much. i will ask the network admin tomorrow ,because today is a public holiday .if i could i would want solve it as soon as possible. i have less time to complete my project :/
 
blackhaz said:
Comment out the [BGCOLOR=#dee3e7] pf_enable="YES"[/BGCOLOR] in /etc/rc.conf, do [BGCOLOR=#dee3e7] service netif restart[/BGCOLOR] as root and see if it helps. Could be some bad firewall rule.
Click to expand...
This won't disable the firewall, it only reloads the interface(s); service pf stop actually disables the firewall. Alternatively, pfctl -d should work too.
 
SirDice said:
This won't disable the firewall, it only reloads the interface(s); service pf stop actually disables the firewall. Alternatively, pfctl -d should work too.
Click to expand...

stopping pf.PNG


I'm guessing PF is already not running. Or I didn't configure any PF yet. So it might not be the problem. I still can't install any packages and can't fetch anything ..
 
bananaceri said:
drill @8.8.8.8 google.com shows :
View attachment 5501
Click to expand...
There is your problem.

I agree with the others that this could be a firewall issue, but it can just as easily also be a problem on your network. You mentioned projects and work: being a sysadmin myself I can well imagine that the guys wouldn't allow you to to contact "rogue" DNS servers and instead expect you to use whatever is locally available (assuming this experimentation is done in a working environment of course). Of course that doesn't explain why the local server didn't work either.

You mentioned 10.82.1.254, might want to test if that works: drill @10.82.1.254 google.com, my assumption is that you'll get the same error which can rule out network related issues.

Alas: pf is not a service you start or stop. It's not some program running in the background, but merely a setting within the kernel that gets turned on or off. Of course it is controlled through /etc/rc.conf and therefor "treated" as a service.

If this is a secure environment (as in: you don't have to worry about remote attackers) then try turning the firewall off: # pfctl -d and then try those drill commands again. If those work then the cause of your issues is indeed the firewall. Next step would be to show us your rules; so share the contents of /etc/pf.conf. You can re-enable the firewall with # pfctl -e.

If you don't trust your environment then obviously keep that firewall activated and just share /etc/pf.conf.
 
ShelLuser said:
Alas: pf is not a service you start or stop.
Click to expand...
It's not a "service" (there's no daemon involved) indeed. But you can still start and stop it using service pf start and service pf stop. See /etc/rc.d/pf. Basically a service pf stop ends up doing a pfctl -d.

But I'm a little worried by the syntax errors in rc.conf. That could cause all sorts of weird and wonderful effects.
 
SirDice does pf not have a "management" script in /etc/rc.d/? It's not a daemon but still allows service or /etc/rc.d/pf to manage it, does it not? Is pf simply a kernel module?

And the syntax errors I see are on lines 10 and 13, should have seen messages from dmesg. man 5 rc.conf
 
ikbendeman said:
SirDice does pf not have a "management" script in /etc/rc.d/? It's not a daemon but still allows service or /etc/rc.d/pf to manage it, does it not? Is pf simply a kernel module?
Click to expand...
Why not simply take a look yourself? ;)

Anyway, /etc/rc.d/pf obviously exists, but is that really important? What's more interesting is what the script actually does:

Code: 
start_cmd="pf_start"
stop_cmd="pf_stop"

<cut>

pf_start()
{
        check_startmsgs && echo -n 'Enabling pf'
        $pf_program -F all > /dev/null 2>&1
        $pf_program -f "$pf_rules" $pf_flags
        if ! $pf_program -s info | grep -q "Enabled" ; then
                $pf_program -eq
        fi
        check_startmsgs && echo '.'
}
This obviously begs the question "What does $pf_program represent?" and that is easily answered once we take a look at /etc/defaults/rc.conf:

Code: 
peter@zefiris:/etc/rc.d $ grep pf_program /etc/defaults/rc.conf 
pf_program="/sbin/pfctl"        # where the pfctl program lives
So if we then look at the start function again we can see that all it does is run # pfctl -F all > /dev/null 2>&1 which effectively flushes everything (see pfctl(8)) while discarding all output. After that it runs # pfctl -f "/etc/pf.conf".

Also:

Code: 
peter@zefiris:/etc/rc.d $ kldstat -m pf
Id  Refs Name
229    1 pf
So yeah, it's definitely a kernel module ;)
 
ShelLuser said:
There is your problem.

I agree with the others that this could be a firewall issue, but it can just as easily also be a problem on your network. You mentioned projects and work: being a sysadmin myself I can well imagine that the guys wouldn't allow you to to contact "rogue" DNS servers and instead expect you to use whatever is locally available (assuming this experimentation is done in a working environment of course). Of course that doesn't explain why the local server didn't work either.

You mentioned 10.82.1.254, might want to test if that works: drill @10.82.1.254 google.com, my assumption is that you'll get the same error which can rule out network related issues.

Alas: pf is not a service you start or stop. It's not some program running in the background, but merely a setting within the kernel that gets turned on or off. Of course it is controlled through /etc/rc.conf and therefor "treated" as a service.

If this is a secure environment (as in: you don't have to worry about remote attackers) then try turning the firewall off: # pfctl -d and then try those drill commands again. If those work then the cause of your issues is indeed the firewall. Next step would be to show us your rules; so share the contents of /etc/pf.conf. You can re-enable the firewall with # pfctl -e.

If you don't trust your environment then obviously keep that firewall activated and just share /etc/pf.conf.
Click to expand...


my pf.conf is empty
 
ShelLuser said:
Why not simply take a look yourself? ;)

Anyway, /etc/rc.d/pf obviously exists, but is that really important? What's more interesting is what the script actually does:

Code: 
start_cmd="pf_start"
stop_cmd="pf_stop"

<cut>

pf_start()
{
        check_startmsgs && echo -n 'Enabling pf'
        $pf_program -F all > /dev/null 2>&1
        $pf_program -f "$pf_rules" $pf_flags
        if ! $pf_program -s info | grep -q "Enabled" ; then
                $pf_program -eq
        fi
        check_startmsgs && echo '.'
}
This obviously begs the question "What does $pf_program represent?" and that is easily answered once we take a look at /etc/defaults/rc.conf:

Code: 
peter@zefiris:/etc/rc.d $ grep pf_program /etc/defaults/rc.conf
pf_program="/sbin/pfctl"        # where the pfctl program lives
So if we then look at the start function again we can see that all it does is run # pfctl -F all > /dev/null 2>&1 which effectively flushes everything (see pfctl(8)) while discarding all output. After that it runs # pfctl -f "/etc/pf.conf".

Also:

Code: 
peter@zefiris:/etc/rc.d $ kldstat -m pf
Id  Refs Name
229    1 pf
So yeah, it's definitely a kernel module ;)
Click to expand...


my pf.conf file is empty ,should i be setting up a pf file? currently, i still can't solve my main problem .really need to find a solution today :/ thank you for all of your feedbacks, i really appreciate it.
 
bananaceri said:
my pf.conf file is empty ,should i be setting up a pf file? currently, i still can't solve my main problem .really need to find a solution today :/ thank you for all of your feedbacks, i really appreciate it.
Click to expand...
What happens if you run drill @10.82.1.254 google.com? Also, what does freebsd-version -ru show you?

Don't bother with an /etc/pf.conf file for now, that can only obfuscate things. Right now I'm starting to think that the cause of your problem lies elsewhere. This is of course assuming that you didn't set up any other firewalls. FreeBSD has 3: ipfw, ipf and pf. Basically: firewall_enable, ipfilter_enable or pf_enable. So if you have any other options in your /etc/rc.conf then that could also be a possible cause.
 
You must log in or register to reply here.
Back
Top