Cannot ping/ssh guest FreeBSD from host Win7

[mlittlejohn]

I'm trying to set up FreeBSD as a VirtualBox guest. I've done a lot of searching and re-creating VMs, twice I've actually had SSH access but I lost it on a reboot after a lot of other setup (Ruby, Github, etc.).

Host: Win7 64 bit
Guest: FreeBSD 64bit 9.1; 1024 MB RAM; 10 GB disk space
VM Network Adapter: Bridged adapter, deny promiscuous mode
Install options: choose no to IPv4 and DHCP setup. sshd enabled

First boot change: /etc/rc.conf to look like:

hostname=".personalVM"
sshd_enable="YES"
dumpdev="NO"
ifconfig_em0="inet 192.168.1.64 netmask 255.255.255.0"
defaultrouter="192.168.1.1"

Change /etc/resolv.conf to:

nameserver 192.168.1.1

In /etc/ssh/sshd_config uncomment PermitRootLogin and change to yes, then reboot.

At this point ifconfig -a shows em0 having the IP address I set. From the guest VM I can ping http://www.google.com as well as the host machine (192.168.1.6, only works when firewall is off).

From the host I cannot ping the VM, connect via WinSCP, or SSH. With ping I get a request timeout.

I have also attempted to use DHCP but similar results. tcpdump shows all sorts of activity but I can't seem to correlate entries with ping or ssh traffic.

 

[wblock@]

First boot change: /etc/rc.conf to look like:

hostname=".personalVM"

Starting the hostname with a dot is unusual. May not matter, may make hostname resolution interesting.

In /etc/ssh/sshd_config uncomment PermitRootLogin and change to yes then reboot.

Please don't do that. It is disabled by default for a reason. Leave it alone, and use su(1).

At this point ifconfig -a shows em0 having the IP address I set. From the guest VM I can ping http://www.google.com as well as the host machine (192.168.1.6, only works when firewall is off).

Which firewall? On the host or the VM?

I have also attempted to use DHCP but similar results. tcpdump shows all sorts of activity but I can't seem to correlate entries with ping or ssh traffic.

On a bridged interface, it's pretty much the same as the VM being a separate physical machine. These sound like firewall issues. Remember that Microsoft has been and continues to be terrified of ICMP, and it shows in the default settings of their Windows "firewall". Also, Windows ping and FreeBSD ping use different packet types. I don't recall which one does it right, but it's reasonable to guess that would be FreeBSD.

 

[mlittlejohn]

Thank you for the quick reply

Starting the hostname with a dot is unusual. May not matter, may make hostname resolution interesting.

I agree it is odd, that dot was put there in desperation after I read on some guide that it expects a dot in the hostname. For what it's worth I've tried with a few different hostnames with and without dots.

Please don't do that. It is disabled by default for a reason. Leave it alone, and use su(1).

I understand the implications of ssh'ing into root directly. I started the first install with a separate user but found that I have to sudo pretty much everything which was getting annoying and this VM will be used exclusively for local development so I don't care if it is insecure.

To test I made a mlittlejohn user just now and I still can't ssh to that user either.

Which firewall? On the host or the VM?

The windows firewall on the host has been completely turned off. I did a quick search and it looks like the FreeBSD firewall (ipfilter_enable="YES") is default off unless you include it in rc.conf which I did not. Is there some other firewall I am overlooking?

On a bridged interface, it's pretty much the same as the VM being a separate physical machine. These sound like firewall issues. Remember that Microsoft has been and continues to be terrified of ICMP, and it shows in the default settings of their Windows "firewall". Also, Windows ping and FreeBSD ping use different packet types. I don't recall which one does it right, but it's reasonable to guess that would be FreeBSD.

The two times where the ssh connection was actually working ping worked as well from Windows -> FreeBSD. That being said I don't care about being able to ping, it's the ssh connection that I'm after.

 

[wblock@]

I understand the implications of ssh'ing into root directly. I started the first install with a separate user but found that I have to sudo pretty much everything which was getting annoying and this VM will be used exclusively for local development so I don't care if it is insecure.

It's good to get in the habit of treating local machines as if they were exposed to the internet. That helps encourage protective habits.

To test I made a mlittlejohn user just now and I still can't ssh to that user either.

Can you use ssh mlittlejohn@localhost on the VM itself?

The windows firewall on the host has been completely turned off. I did a quick search and it looks like the FreeBSD firewall (ipfilter_enable="YES") is default off unless you include it in rc.conf which I did not. Is there some other firewall I am overlooking?

FreeBSD has three firewalls. IPFW and PF are the most common, there are still some people using IPF. All are off by default.

The two times where the ssh connection was actually working ping worked as well from Windows -> FreeBSD. That being said I don't care about being able to ping, it's the ssh connection that I'm after.

 

[mlittlejohn]

After ssh'ing from root to my user in the Virtualbox console I could once again ping and ssh from my Windows machine into the VM. This let me revive the original VM I had made with a lot of setup. Thank you.

 

[mlittlejohn]

Actually my post above is incorrect. I just happened to do this after my Junos Pulse VPN session from earlier had died. From some testing it looks like I can use an already in session ssh connection (Win7->FreeBSD) without any issues even after logging into the VPN. However once logged in I cannot create a new ssh connection to FreeBSD.

 

[wblock@]

After sshing from root to my user in the virtualbox console I could once again ping and ssh from my windows machine into the VM. This let me revive the original VM I had made with a lot of setup. Thank you

I don't know what problem that would fix. Something else may be at work, and the problem may come back.

 

[tingo]

Some VPN setups forces all traffic to be routed through the VPN tunnel. That could be the case here.