| View previous topic :: View next topic |
| Author |
Message |
tclover
Guru
Joined: 10 Apr 2011
Posts: 516
|
 Posted: Tue Aug 09, 2016 10:14 am Post subject: [SOLVED]VMware networking - cannot reach OUTSIDE WORLD |
 |
|
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.
But if someone speak with you, it will not sent any mac destination, as it doesn't know with who it should speak with.
At this point the nat is trying to figure out to who it should sent it to:
- first it will seek if you have a rule for the port that get query, and sent the info to that computer if one is define, that's the forwarding port rule of nat
- if no rule exists, it will than seek out if one of your computer is set as dmz host, and any info that is not for a computer and have no forwarding port rule set will be sent to this host.
If you have no forwarding rule and no dmz set, your nat is just unable to route your ssh query to your host. It doesn't mean one of your computer setup is not fine.
So are you sure your router have the needed clues to sent your ssh query to your vm? |
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:
| forward_from_host_to_guest.sh: | #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:
| ipr.sh: | 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:
| iptables -L (reduced to vmnet[18]): |
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.
_________________
home/:mkinitramfs-ll/:supervision/:e-gtk-theme/:overlay/
Last edited by tclover on Mon Aug 15, 2016 10:43 pm; edited 1 time in total |
|
| Back to top |
|
 |
gordonb3
Apprentice
Joined: 01 Jul 2015
Posts: 185
|
| Posted: Wed Aug 10, 2016 8:23 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
tclover
Guru
Joined: 10 Apr 2011
Posts: 516
|
| Posted: Mon Aug 15, 2016 10:56 pm Post subject: |
|
|
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:
| NAT: |
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.
_________________
home/:mkinitramfs-ll/:supervision/:e-gtk-theme/:overlay/ |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Networking & Security
