# [SOLVED]VMware networking - cannot reach OUTSIDE WORLD

## tclover

I can ping and ssh to guests when using what VMware calls NAT-network and host-only network. The bridged configuration does not work here, I cannot get anything out of the VM OSes. I guess I need some help from  somes expericnaced users to this stuff because VMware howtos are almost useless for no M$ Windows users. Well, it does explain how to install their offering and then advise to remove anything that can be in their way.

I could ping out to the internal network before with the NAT-network configuration, but it does not work anymore. I tried a few configuration settings change with vmware-netcfg which I reverted because I did not do any difference. The weird stuff is that the host-only network configuration can resolve the route to the ouside world; while the NAT-network cannot which should be the opposite.

Lets start with what should be done resumed by krinn in topic 1043554:

 *krinn wrote:*   

>  *PutinIsLove wrote:*   So the problem is i can' t ping my VM from my desktop pc but i can ping my desktop from gentoo. 
> 
> If you have a working connection and are unable to openssh the vm, it might just be because the vm is hidden behind the nat.
> 
> When you speak with internet, your card sent its mac address with your IP and the one you speak with answer with that mac in the packet, and the nat know who need to get the packet.
> ...

 

And the issue with VMware is that the network forwarding is done by the virtual network interfaces themselves and not by the firewall, and this might the source of this issue.

Any good howto found in the intertube, by opposotion to VMware howto wich just plain explain to remove any firewall to avoid having issue (is this a bad joke) give this simple IPTables scripts to get going:

```
#Enable forwarding (same step as on the guest VM).

echo '1' > /proc/sys/net/ipv4/ip_forward ;

#Flush the iptables NAT table (remove all prior rules)

iptables --table nat --flush ;

#Apply the masquerade extension to all outbound packets

iptables --table nat --append POSTROUTING --jump MASQUERADE ;

#Tell the default virtual interfaces to accept forwarded packets

iptables --append FORWARD --in-interface vmnet1 --jump ACCEPT ;

iptables --append FORWARD --in-interface vmnet8 --jump ACCEPT ;

#Translate (by DNAT extension) incoming TCP packets from port

#   65524 to the virtual gateway (192.168.87.1) port 65524

iptables --table nat --append PREROUTING \

  --protocol tcp --destination-port 65524 \

  --jump DNAT --to-destination 192.168.87.1:65524 ;
```

This one is from how-to-redirect-network-traffic-to-your-virtual-machine

I have a more restricted rules and so I had to to modify that to:

```
ipt=/sbin/iptables --modprobe=/sbin/modprobe

snat=1 nat=1 ipv4=1

ext=eth0 int=vmnet1 vmn=vmnet8

# Allow MSQUARADING for NAT/DSL-Router

if [ -n "$nat"  ]; then

  $ipt -t nat -A POSTROUTING -o $ext -j MASQUERADE

  # NAT I/O

  if [ -n "$ipv4" ]; then

    $ipt -A PREROUTING  -t nat -j ACCEPT

    $ipt -A POSTROUTING -t nat -j ACCEPT

    $ipt -A OUTPUT      -t nat -j ACCEPT

   fi

fi

# Allow NAT for bridged NAT/DSL-Router

[ -n "$snat" ] && $ipt -t nat -A POSTROUTING -o $ext -j SNAT --to 192.168.0.10

# Accept trafic from internal interface

for interface in ${int//,/ } ${vmn//,/ }; do

  eval set -- $(ifconfig ${interface%:*} | sed -nre '/inet /p')

  while [ $# -gt 0 ]; do

    eval "${interface}${1}=${2}"

    shift 2

  done

  if [ -n "$ipv4" ]; then

    eval network="\$${interface}inet/24"

  else

     eval network="\$${interface}inet/64"

   fi

   $ipt -A INPUT    -i $interface -s $network -j ACCEPT

   $ipt -A FORWARD  -i $interface -s $network -j ACCEPT

   $ipt -A OUTPUT   -o $interface -s $network -j ACCEPT

   case ",${vmn}," in

      (*,${interface},*)

      $ipt -A INPUT    -i $ext -d $network -j ACCEPT

      $ipt -A FORWARD  -o $ext -d $network -j ACCEPT

      ;;

   esac

done

```

The entire ipr.sh script is over there.

The last rules for vmnet[18] will gives this:

```

Chain INPUT (policy DROP)

target     prot opt source               destination

ACCEPT     all  --  192.168.70.0/24         anywhere

ACCEPT     all  --  172.16.178.0/24         anywhere

ACCEPT     all  --  anywhere             172.16.178.1

Chain FORWARD (policy DROP)

target     prot opt source               destination

ACCEPT     all  --  192.168.70.0/24         anywhere

ACCEPT     all  --  172.16.178.0/24         anywhere

ACCEPT     all  --  anywhere             172.16.178.0/24

Chain OUTPUT (policy DROP)

target     prot opt source               destination

ACCEPT     all  --  192.168.70.0/24         anywhere

ACCEPT     all  --  172.16.178.0/24         anywhere

```

I have nothing dropped, rejected in IPTables going from/to vmnet[18]. So, I don't know where the packets are going. If I remove that for loop, I can pretty much see the packets being dropped and rejected... so adding that whole for loop is necessary. Now, where are going the packets when requesting a ping to internal network machines or to ISP? I could understand that vmnet8 forwarding as being at fault. Now, why that host-only vmnet1/192.168.70.128 does not work? I can see in the guest that route for internal and external network is being resolved but nothing get back; and nothing is logged as being dropped or rejected.

Thanks.

EDIT: Indeed, if I remove IPTables nat rules the host can still ping or ssh in; but nothing from guest get back... host-only still can resolve the route to outside world.

----------

## gordonb3

Well, to start with it makes a lot of sense that "host-only" doesn't work that way if you added forwarding capabilities and masquerading rules to your host. The firewall will likely also confuse the NAT protocols on vmnet8, that are operating at a different level (so NF conntrack won't know about your outbound connections). I don't really know why vmnet0 doesn't work for you. On my machine it runs without issues and I have in fact disabled vmnet1 and vmnet8. What I do know is that your network adapter must support the bridge protocol. It may therefore be a hardware or driver related issue that prevents you from using vmnet0.

Unless you really need that firewall because you are directly connected to the internet, I'd start by running without it and disable forwarding in your kernel. Make the box as default as possible.

----------

## tclover

There were more to NAT rules than what is found on most guides found in the intertubes; the whole story is over there NAT rules. Basically, the MASQUERADE is a short and inefficient way to NAT. Using a more complete and efficient rules is welcomed... first to get what and how to do proper NAT rules.

Here is how I do it now with more restrictions and dynamic IPTables rules:

```

int=vmnet1,vmnet8 ext=eth0 (inet=192.168.0.x net=$inet/24 obtained with DHCP server)

ifc=ifconfig ipt=iptables sed=sed cidr=24

   for interface in ${int//,/ }; do

      eval set -- $($ifc ${interface%:*} | $sed -nre '/inet /p')

      while [ $# -gt 0 ]; do

         eval "${interface}${1}=${2}"

         shift 2

      done

      eval address="\$${interface}inet"

      $ipt -A INPUT   -s $address/$cidr -d $inet    -j ACCEPT

      $ipt -A OUTPUT  -s $address/$cidr -d $inet    -j ACCEPT

      $ipt -A FORWARD -s $address/$cidr -j ACCEPT

      # Allow NAT-ing for internal interfaces (use those for port redirect with --dport=<N> --sport=<N> only

      #$ipt -A INPUT       -t nat -d $inet    -j SNAT --to-source $address

      #$ipt -A PREROUTING  -t nat -d $inet    -j DNAT --to-destination $address

      #$ipt -A POSTROUTING -t nat -s $network -j SNAT --to-source $inet

      #$ipt -A OUTPUT      -t nat -s $network -j DNAT --to-destination $inet

      # Allow router masquerading

      $ipt -t nat -A POSTROUTING -o $ext -s $network -j MASQUERADE

   done

```

What's was the issue? DNS mainly because I can reach the outside world now with those rules... but the guest (FreeBSD) can't do name resolution. I will look at it later. I could solve the issue quickly on a Linux guest... but I am not that familiar with FreeBSD yet. The other issue regarding host-only connectivity is that there is no route configured to reach outside world; I will try adding a route later and see what happen with that configuration. This setup is indeed a natural firewall because nothing can reach those guests... but with the above NAT rules and a route addition to guests.

----------

