Block NAT on the network?

TeeJayHoward

TeeJayHoward

Limpness Supreme
Joined
Feb 8, 2005
Messages
12,264
Imagine the following scenario: You're in charge of a small-medium sized network. Say, 4,000 users. You use the 10.x.x.x IP range. Certain blocks are reserved for certain things. For example, the 10.0.2.x range is used by the networking team. Obviously your DHCP server doesn't hand out IPs in that range. While browsing the DNS entries recently, you noticed that a lot of clients have IPs in the 10.0.2.x range. Confused, you track them down. They're all clients running VirtualBox.

Apparently, VirtualBox includes a built-in DHCP server when using NAT, which hands out IPs in the 10.0.2.x range for the first NIC, 10.0.3.x for the second, etc. This is creating an issue. If the clients switch to bridged networking, they use your DHCP server, and everything is gravy. Tracking down every user who is using VirtualBox and having them change their settings manually is a pain. Instead, you decide that there must be a way to prevent the VMs from talking to your network unless bridged networking is set up.

How would you go about doing that?
 
Where's the issue if the clients use 10.0.2.x behind their own virtual NAT? The addresses shouldn't appear outside the host and if you don't have a route to them, they shouldn't be able to do anything.

As usual: draw a map.
 
TCM said:
Where's the issue if the clients use 10.0.2.x behind their own virtual NAT?
Click to expand...
The issue arrives when your DNS server sees that the IP addresses are in use, and prohibits other devices from using said addresses.
 
ACLs on the core router/switch denying all 10.0.2.0/24 traffic inbound source or outbound destination depending on how your switch does ACLs
 
TeeJayHoward said:
The issue arrives when your DNS server sees that the IP addresses are in use, and prohibits other devices from using said addresses.
Click to expand...

This doesn't make any sense. A DNS server translates hostnames to IP addresses and vice versa. It doesn't regulate what addresses clients get.
 
TCM said:
This doesn't make any sense. A DNS server translates hostnames to IP addresses and vice versa. It doesn't regulate what addresses clients get.
Click to expand...
I've worked with DNS/DHCP appliances before that do this kind of "sanity" check.
 
Wait, are ordinary clients allowed to update records belonging to the network team? Looks like the whole setup is FUBAR and needs a good hard look to be done right.

"Blocking NAT" is 1) impossible 2) a bigger screwup to cover the first screwup. What a mess.
 
Kill their install rights, reimage the machine with VB set correctly and be done with it, and stop letting anyone install any program they feel like on a whim on your network.
 
XOR != OR said:
I've worked with DNS/DHCP appliances before that do this kind of "sanity" check.
Click to expand...

Don't these appliances use ICMP to do this check? If that's the case, then obviously it won't route to the VM when doing the check. \o/

Also, -Dragon-, ACLs won't work since the DNS data is in a packet being sent from an address that you obviously allow on the ingress.

The only feasible way I know is Kwisatz suggestion or disable DDNS for that zone.
 
While browsing the DNS entries recently, you noticed that a lot of clients have IPs in the 10.0.2.x range. Confused, you track them down. They're all clients running VirtualBox.
Click to expand...
AFAIK this problem comes about when your DHCP server does not have the correct settings for WINS Netbios lookup, but insecure DNS registrations (NetBIOS responses) are permitted and:
1)perr-to-peer NetBIOS-over-tcp (broadcast) lookup traffic is permitted on the local subnet
-or-
2)ip gateway proxy is permitting NetBIOS-over-tcp (broadcast) traffic across subnets
-or-
3)NetBIOS multicast is allowed on your network

I'm pretty sure that Virtualbox acts as a "helper proxy" for DNS and WINS to its guests. By this, I mean that if DNS is configured properly or the WINS DHCP option is set, DNS/WINS reponses from the VB guests will be changed from the internal VB IP address to the machine's "proper" IP address.

If you want to stop ONLY the VMs from responding to Netbios name queries, I think you will need some form of netbios-over-tcp packet inspection (ie, block a packet where a machine on subnet 1 is giving a netbios response that says it is on subnet 2).


The issue arrives when your DNS server sees that the IP addresses are in use, and prohibits other devices from using said addresses.
Click to expand...
That is why I think it is better not to enable name&reverse name protection unless you also require secure DNS registration. With Windows DNS, is also possible to turn off name protection only for NetBIOS responses, yet leave it enabled for "real" DNS responses.
 
Last edited:
Err...what I was trying to say is that NAT is not causing the problem. The bad DNS registrations are coming from Netbios. Netbios was never intended to work with NAT, and makes the (stupid) assumption that Netbios names uniquely identify network interfaces.
 
Build an ACL between the VirtualBox server and the DNS server blocking NetBIOS traffic sourced from the outside NAT IP address of the 10.0.2.0 network.

Sounds like thefreeaccount has a good idea of your root problem though.
 
Then the outside address hosts can't update DNS either, which is probably not desired.

You'd have to do packet inspection and filter (do something) upon that, not allow the request in the 1st place or not honor the request, all of which have pros and cons.
 
Last edited:
squishy said:
Then the outside address hosts can't update DNS either, which is probably not desired.

You'd have to do packet inspection and filter (do something) upon that, not allow the request in the 1st place or not honor the request, all of which have pros and cons.
Click to expand...

I said the IP address (singular) of the VirtualBox, which is the outside NAT for the clients. Unless VirtualBox does something like make 1:1 NATs for each of the clients, which would be weird. Generally an overloaded outside NAT IP won't need to be making DNS entries.

It's possible I'm not understanding the topology though. I'm a WAN tech so I haven't worked with VirtualBox in a LAN environment personally.
 
No worries, I think both of you are on the right track and it's a mildly interesting problem. Heck I'm a unix admin but even I like windows problems from time to time :)

If the VM does DNS registration via Netbios and the host (assuming Windows 7) does DNS registration either via vanilla UDP coupled with a kerberos token, then filtering Netbios from the host address net like you suggest would work (and I think this is the case).

If the VM does DNS registration via vanilla UDP and the Virtualbox host does not do a kind of "fixup" for the request, then obviously that won't work. As far as the VM is concerned, it's sending accurate information.

It would be simple enough to see and understand the exact behavior with a few test machines, but coming up with a solution may or may not be trivial, as usual :)
 
Disable DDNS updates. NOC team should have static addresses anyway and be separated from ordinary clients and ordinary clients should in no way be able to update DNS.

I'm baffled this can be an issue at all with proper network hygiene practices.

All this messing about with "blocking NAT" and "packet inspection" and what other horror methods you guys come up with is rolling up my toenails. Seriously.
 
TCM said:
Disable DDNS updates. NOC team should have static addresses anyway and be separated from ordinary clients and ordinary clients should in no way be able to update DNS.

I'm baffled this can be an issue at all with proper network hygiene practices.

All this messing about with "blocking NAT" and "packet inspection" and what other horror methods you guys come up with is rolling up my toenails. Seriously.
Click to expand...

I'm laughing as I read this. You have no idea of the needs of the OP's networking team or the hosts on his network and yet you feel qualified to ridicule the solutions we've provided which attempt to provide an answer to the OP's issue without making unnecessary assumptions as to how his network works.

I've seen that trend in your posts. Drop the "holier than thou" attitude and don't presume that with a brief explanation from the OP regarding his network that you understand how it should be set up. I provide consultations on enterprise networks day in and day out, and I learned a long time ago that what often sounds stupid often has a purpose, for better or for worse. Sure, sometimes it doesn't, and it's just plain stupid. But assuming that has a tendency to make one look the fool.
 
You must log in or register to reply here.
Back
Top