Block NAT on the network?

TeeJayHoward

Limpness Supreme
Joined
Feb 8, 2005
Messages
11,167
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?
 

TCM

Gawd
Joined
Nov 10, 2011
Messages
641
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.
 

TeeJayHoward

Limpness Supreme
Joined
Feb 8, 2005
Messages
11,167
Where's the issue if the clients use 10.0.2.x behind their own virtual NAT?
The issue arrives when your DNS server sees that the IP addresses are in use, and prohibits other devices from using said addresses.
 

-Dragon-

2[H]4U
Joined
Apr 6, 2007
Messages
2,316
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
 

TCM

Gawd
Joined
Nov 10, 2011
Messages
641
The issue arrives when your DNS server sees that the IP addresses are in use, and prohibits other devices from using said addresses.

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.
 

XOR != OR

[H]F Junkie
Joined
Jun 17, 2003
Messages
11,549
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.
I've worked with DNS/DHCP appliances before that do this kind of "sanity" check.
 

TCM

Gawd
Joined
Nov 10, 2011
Messages
641
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.
 
Joined
Jul 6, 2010
Messages
627
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.
 

squishy

[H]ard|Gawd
Joined
May 25, 2006
Messages
1,209
I've worked with DNS/DHCP appliances before that do this kind of "sanity" check.

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.
 
Joined
Aug 8, 2010
Messages
832
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.
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.
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:
Joined
Aug 8, 2010
Messages
832
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.
 

Electrofreak

[H]ard|Gawd
Joined
Aug 5, 2008
Messages
1,080
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.
 

squishy

[H]ard|Gawd
Joined
May 25, 2006
Messages
1,209
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:

Electrofreak

[H]ard|Gawd
Joined
Aug 5, 2008
Messages
1,080
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.

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.
 

squishy

[H]ard|Gawd
Joined
May 25, 2006
Messages
1,209
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 :)
 

TCM

Gawd
Joined
Nov 10, 2011
Messages
641
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.
 

Electrofreak

[H]ard|Gawd
Joined
Aug 5, 2008
Messages
1,080
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.

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.
 
Top