Is it possible to force clients into using the ip addresses defined in the static leases?
I have configured my laptop to use 192.168.1.107, but it can still use another ip by not using dhcp.
Is it possible to prevent that, other then maintaining a whitelist of allowed ips in the firewall?

I can't think of any other way than whitelisting MAC + IP address combos in your firewall. To make matters easier you could probably make some script that runs whenever a lease is assigned, and adds MAC + IP address to the whitelist. That way, a device not using DHCP would not be allowed outside access at all, and since a static lease is configured it will always receive the same IP address.

I doubt it's foolproof, but it sort of accomplishes your goal.

Hi Makro, thanks for the reply. The obvious attack scenario I see with this approach is that MAC addresses can easily be faked. So an attacker could fake my laptop's MAC address and gain access while I am not in the network. Or even while I am, I am sure damage can be done even with a duplicate IP within a LAN.

Originally you asked how to prevent your own PC from using another IP address than the one it gets via DHCP. And makro gave an answer to that question.

But in your second message the problem has changed into something else... Now somebody is already faking MACs and you are worried about attackers entering the network.

If you do not trust MAC addresses, then you might be looking for certificate-based WPA enterprise mode authentication for the WLAN client in the first place. The attacker should then both fake the correct MAC and have also the needed certificate file.

(simplest might just be to turn off wifi and use only physical LAN.)

No. I asked "Is it possible to force clients into using the ip addresses defined in the static leases?". The laptop part was just to give an example where the system's current behavior deviated from what I am trying to achieve.

Can't remember having mentioned WLAN. I am talking about ethernet connection, which admittedly I did not mention either.

Let's start over, with the often needed question: what are you actually trying to accomplish? Forcing clients to use the IP addresses defined as static leases is a solution to a problem. We don't know what that problem is, we only know that you need help implementing what you see as the solution to said problem.

Something that crossed my mind when I wrote my first reply, which I didn't type out (because the problem was not clear), is that there is no enforcement in DHCP. DHCP is a protocol meant to help devices that don't know any better on a network. It doesn't, and shouldn't (considering its purpose), care about network devices who know what they want, whether they have malicious intentions or not.

As you are worried about someone impersonating you (or your device), the problem seems to be related to authenticating network devices. You seem to want to be able to trust that devices in your network are under your control, or otherwise are not allowed to use your network. You have already pointed out that trusting MAC addresses isn't sufficient for your use case, and so neither is IP addresses. 802.1x may be a good fit, it is widely supported in operating systems and in many business grade network devices (network printers and such). Another solution is using a local VPN, where all clients need to connect to a VPN gateway to gain network access - devices not connected to VPN will only have access to the VPN gateway (in order to establish a connection).

But I'm derailing this, so back on track: what is your problem or need, that you are trying to solve or fulfill?

Hi Makro, thanks a lot for your detailed reply, and sorry for answering late, I think I forgot to subscribe to the topic. You are right, I probably should have described what I want to do in more detail.
I am running a webserver on a VM using virtualbox. Both the guest and the host are running Linux and are using the same ethernet interface.
The webserver is publicly visible through a port forward. My goal is to come up with a setup in which the webserver can be accessed from wan, the vm can be accessed via ssh from lan, but the vm is unable to initiate any connections whatsoever into lan. I want it to be able to initiate connections to wan though.
When I posted the question I was using a network bridge in virtual box, which meant that the vm was in the same LAN as the host (and other clients). So I wanted to use firewall rules to isolate the vm, which in turn would only work reliably if I could depend on the vm always having the right ip.

After more research I came to the conclusion that I needed to create a seperate vlan. I have fiddled around a bit with this for like two days and to be honest I could not get it to work. I also thought that even this approach would end up not being completely secure.

So now I have solved the problem in a completely different way. (Well at least I think it's solved). I am now using NAT rather then bridging in  virtualbox. So now I only need to care about protecting the host from the guest. Which can be done in a reasonably straight forward way in iptables.

Long story short: My original problem is solved. I would still be interested how to get the vlan stuff to work, but I guess it would make sense to open a new thread for that...

Thanks again for your help!

I build the exact same thing using VLANs.

Host- and guest-system Debian, KVM for virtualisation and openvswitch to deal with the VLAN-separtion/tagging. The VLAN-processing is done on the host-system only, so the guest-system can't tamper with the VLANs. This way you get a secure DMZ.

check out this documentation:
http://zcentric.com/2014/07/07/openvswi … right-way/
http://www.jackwparks.com/2014/06/home- … tch-vlans/

Thanks for this. It will take me a while to digest this information though :-)
I will post back when I got the chance to take a close look...

Sure, and for the record, I needed a lot of time to get it running, mostly because openvswitch didn't work out of the box. (But it was debian testing 2 years ago, maybe a lot of changed since than, or other distros are better)

So if you don't want to deal with openvswitch (or you can't get it work with virtualbox), maybe getting an additional networkcard is the easiest solution. Bind the VM to this interface and connect it to a switchport  on your openwrtrouter which is in a separate VLAN.

(Last edited by eleon216 on 10 Jan 2015, 13:38)

Ok, so if I understand this correctly this completely removes the need for setting up vlans in openwrt. This sounds like a good way to do it.
At this point I doubt that I should go through the hassle though (thanks for the warning) since my current setup seems to do what I want.

I'll definitely bookmark the links for future use though. Thanks again.

No, it doesn't  removes the need to set up vlan on the openwrt-router, it's just a secure way to separate the guest from your LAN on layer2, with only one physical networkinterface on your server.
And to be honest I'm curious how you got a secure setup using NAT (on your server) for the networkinterface of your guestsystem.

I think openvswitch is not necessery, it should be possible just with bridgeutility, too.
Like here, in section "Adding VLANs to the mix – the usual guest access mode":
http://blog.davidvassallo.me/2012/05/05 … he-guests/

It's only important, that the VLAN-tagging takes place on the hostsystem (which is trustworthy) and not on the guestsystem. So all packets from/to your guestsystem are tagged with a specifc vlan (and the guestsystem cannot change this!). On your openwrtbox you enable VLAN-trunking on this switchport, define an own network (DMZ) for this vlan and then configure everything else (routing, firewall,...) on the openwrtbox only.

And it will be more secure because the separation happens on layer2 and not on layer3, and you only have to administer one firewall-configuration (on your openwrtbox) and not two (openwrt and server). So it's maybe more work to set it up, but in the end the overall-complexity of your network-structure is reduced. And really no traffic needs to run through your LAN (in contrast to your current setup).

So you get the same level of separation as if you would put an additional networkcard in your server, bind the guest (exclusively) to it, and define the switchport on your openwrtbox as a separate VLAN. Just without addional hardware.

Hi Eleon

thanks for the clarification. Ok, I see. I thought you could do the whole VLAN tagging stuff with openswitch on the host. This makes the "barrier" to start another attempt at this for me even higher. I was really struggling when trying to set up the VLAN stuff on openwrt. And I kept cutting myself off, which is painful.

Well through NAT the guest can only "see" the host, and no other LAN clients. And I am protecting the host through firewall rules that block all traffic initiated by the guest.
The host sees traffic from the guest as traffic generated by the virtualbox process. If the traffic is targeted at the host the destination ip is 127.0.0.1. So I only need to run virtualbox using a dedicated usergroup and define the following firewall rule

iptables -A OUTPUT -m owner --gid-owner virtualbox -d 127.0.0.1 -j DROP

Now the guest can access WAN but is completely isolated from the LAN. I have some additional rules but I guess you get the picture.