Sign up and stay connected to your favorite communities.

sign uplog in
0

Deploy a DHCP server with no IP adress on NIC serving DHCP requests? (Raspberry Pi?)

I have a fringe case. Dont know how to do this. Hope you can help point me at the right direction.

I have a VPN appliance that needs DHCP provided internet connection to connect, and call home. (Kindda like Meraki stuff).
The device needs to be able to pull an IP, DNS and GW info from a DHCP server to operate.

BUT i have a location where the only kind of reliable internet can only be had with a single static IP, and the ISP will not provide DHCP for the connection.
Right now i have made a McGuiver solution, and just plugged in the first available homegrade router i could find at the office. Plugged this in between the ISP connection and the VPN box, just to be able to provide the VPN appliance with a DHCP issued IP and GW + DNS, so it can connect home to our main firewalls.

Since i dont trust this homegrade router to keep running without nursing, i need something better to replace it.

I could spend an arm and a leg to put in a quality router, to take its place. But as the router is absolutely just another route that is entirely unneeded, i would rather find a way to hand out those DHCP requests instead.

So now i am getting out of the comfort zone on this.
All DHCP servers i have ever setup (Windows, BSD, Linux, FW applicances all had an IP adress on a interface to be able to set them up as DHCP servers.

Is there any way i can just setup a Rasberry Pi on the same switch to hand out the one IP adress i need, without it having to have an IP on the same network?

The network on the public IP is a /30 (255.255.255.252) network, where my device have one IP, GW have another, one for broadcast, and one to define the net. So there is (to me) no way to place a DCHP server in this adress space.

I have no network training or education. So if all of this sounds just silly/crazy to any of you, i appologize, and just ignore me.

EDIT: Thank you for all the nice ghetto hacks you have suggested. I will give some of them a try.

28 comments
25% Upvoted
What are your thoughts? Log in or Sign uplog insign up
CCNA
5 points · 10 days ago

You're ABSOLUTELY CERTAIN that this VPN device can't be set to a static IP address? Because that sounds very strange to me. If I were you, I'd open up a support case with the manufacturer of the device and ask how to set it up on a static IP.

Original Poster1 point · 10 days ago · edited 10 days ago

Yep - 100% certain.
Thats kindda the purpose of the device. You buy it, register it in you main UTM, plug device in to internet at some offsite location, device makes tunnel back to HQ. There is NO configuration options on these devices. They are made, so if anything ever breaks, i can just tell one of the "turfs" to come by my office, and pick up a spare, plug it in, and they are up and running again. (Even if i am not at the office that day, i can tell them to just grab one of those spare devices on X shelf at Y room, and it will just work!)

3 points · 10 days ago

What vendor/model is it?

Original Poster1 point · 9 days ago

Sophos UTM + Sophos RED VPN devices

And to rule things out, you are using current version of firmware?

2 points · 10 days ago

You can cheat at TCP/IP and manually assign the IP address of the server (say a Raspberry Pi) to be the broadcast IP address and run DHCPd.

This is a very bad thing to do in a healthy network, but it should work for your purposes -- it'll run as a DHCP server and hand out the one IP address, but probably will not be able to communicate otherwise.

It's a horrible hack, but it is a solution.

Original Poster1 point · 9 days ago

Nice idea...

CCENT, CCDA, JNCIA, VCP4
1 point · 10 days ago

I don't have any technical solution for what you are asking, just an initial thought. I would try to keep this remote location AS SIMPLE AS POSSIBLE. Setting up an extra device would not be my first solution, as that is just another piece of equipment that could fail. What about using a different VPN endpoint, something like an all in one firewall (ASA is what I have experience with)? You would put a rock solid config on it, deploy it, and only need to do routine firmware updates.

Original Poster1 point · 10 days ago

I have the same concern about putting in another device that might fail.

That is why i would rather go for an easily replaceapple Raspberry that only hands out the IP adress for the VPN device. No extra routing, natting or hardware BETWEEN the VPN device and the GW.
This way, even if the Raspberry dies, the connection would still be running until a powerfail would make it request a new IP adress. It is cheap, so a spare would be placed right next to the working one, and the staff can be guided to replace this - they are mostly technically gifted, and all network cables is colour coded and marked. (Also we have a backup 4G/LTE connection to take over, in the event of a failure).
To me this would still be better than having all traffic passing through an extra router - that if dying - would halt all traffic.

I get what you are saying about the ASA device. But we are using Sophos UTM firewalls + RED devices for these deployments everywhere else, and it is rock solid. So putting in a new ASA at HQ + remote location, just to solve this irritating problem of a single ISP that cannot give us a DHCP supplied internet connection would be a massive overkill! (By the way. Is it normal to get a business quality fiber connection, and NOT be able to just get a connection with just DHCP supplied internet access??? I told them i dont even need that static IP adress, just stable internet with a decent SLA! I am starting to think i would have been better off just buying a home subscription fiber of the same speed, with no SLA or any kind of service level...)

Is it normal to get a business quality fiber connection, and NOT be able to just get a connection with just DHCP supplied internet access

I suppose it depends on the ISP. We have a 30Mbps business internet connection with a carrier for some not so critical stuff like testing and WiFi. They provided us with a dedicated static IP but we can also obtain one via DHCP.

Could supernetting two /30 networks, one with the dhcp server and the other for the client devices work in this case?

Original Poster1 point · 9 days ago

Hmm... didnt think of this. I wil give this a look.

1 point · 9 days ago · edited 9 days ago

Assuming (in this example) that your ISP wants you to use these settings to get to internet:

IP: 10.0.0.1

MASK: /30 (255.255.255.252)

GW: 10.0.0.2

DNS1: 10.1.0.1

DNS2: 10.2.0.1

  1. The dirty method:

Connect a random L2-switch with at least 3 interfaces available to the uplink and connect your VPN and your RPI to this switch (which sums up to 3 interfaces being used in total).

For example:

int1: VPN

int2: RPI

int3: ISP

Configure the RPI to use ip 192.168.0.1/24 (or whatever RFC1918 range you prefer) and no default gateway on its own interface.

Configure DHCP-server on the RPI. Preferly through a mac-address asignment so your VPN always gets the same ip no matter what the leasefile says.

Tada!

2) The clean method:

Get a L3-switch and configure DHCP-snooping and DHCP-relay on it, make sure there is no snooping/relaying happening on the interface towards ISP. Relay DHCP-requests towards 192.168.0.1.

Its up to you how you configure int1 and int3 ip wise (none is needed for this case) but int2 is configured with 192.168.0.254/24 (this is what your RPI will use a default gw). Note that in some cases you are forced to configure an ip interface towards teh VPN anyway for the relay to work properly and in that case this example (no 2) wont work unless you also do NAT or have the ISP to route a different range over the already existing linknet.

Tada!

The point with the clean edition above is that you dont expose your DHCP-server towards your ISP. Your ISP should filter any DHCP replies coming through your connection but better safe than sorry (so you dont screw things up for other customers who accidently used DHCP, its also good once the ISP starts to do DHCP on purpose or by accident you still force the DHCP-requests to end up at your RPI and nowhere else).

What happens here is that even if your ISP uses this /30 you can have multiple networks on the same L2 domain (as with the 192.168.0.1/24 which the RPI will use).

So when your VPN box DHCP-clients sends a DHCP-request as a broadcast this will be pick up by your RPI who then replies to the mac address of your VPN that it should use the ip 10.0.0.1/30 along with GW 10.0.0.2 and DNS1 and DNS2 (or whatever ip there is in your case).

Now when the lease is about to go out your VPN DHCP-client will try to reach to the 192.168.0.1 box. However since the VPN have 10.0.0.1/30 configured as ip (through DHCP) it will not be able to reach to 192.168.0.1. When it fails last resort is to send a new broadcast before it finally dies due to the lease expires. Once this broadcast is sent your DHCP-server (RPI) will pick this up and the mac address filtering will return the ip 10.0.0.1/30 (or whatever it is in your case) to your VPN box.

2 points · 9 days ago

A really dirty method would be to use tcpdump to record a full DHCP transaction with offer/acknowledge that you store in a pcap-file and then just have that being looped (through tcpreplay) once a second so your RPI once a second sends out an offer and an acknowledge blindly to the mac address of your VPN box.

Downside with this is that there is an transaction id and a magic cookie which will most likely fuck things up for this really dirty hack to work (since they are both unique for every DHCP request).

Another (if you dont want to run a full DHCP server) would be to listen for incoming DHCP requests towards udp67 on your RPI, extract the transaction id and magic cookie and create a valid reply back to the VPN box so it will set its ip through DHCP.

If you use the rapid deployment setting in the DHCP standard only a single packet is needed back to the VPN box (instead of two which you normally use).

2 points · 9 days ago

A really dirty method

I'm trying to have lunch over here!

You're a sick man, and I applaud you for it :D

Original Poster1 point · 9 days ago

You sir, have a really dirty mind!
I like your style - ghetto to the max!

Whatever is needed to resolve the situation - Improvise, Adapt and Overcome :-)

Herder of Packets
1 point · 9 days ago · edited 9 days ago

You could also use a not so random l2 switch that supports an on board DHCP server; Cisco 2960G can be had for cheap on ebay and are rock solid. There's even an 8 port model without fans (2960G-8-TC-L) in case it needs to be placed in an office.

Edit: Still needs an IP address.

Original Poster1 point · 9 days ago

Edit: Still needs an IP address. Yep, theres my problem with this type of solution. Thats why i need to do this without needing an IP adress on the same /30 subnet that i have to hand out the IP adress to...

Herder of Packets
1 point · 9 days ago

Thing is, DHCP uses unicast after the initial discovery so won't work without the server having an IP address.

/u/Apachez showed some possible solutions some of which could be combined with an intelligent switch so reducing the complexity by removing the proposed RPi.

You dont need an ip on the same subnet, you can use another subnet.

Thing is that the initial dhcp discovery is sent as broadcast with no ip set. The dhcp offer responds with ip of the dhcp server but response directly to the mac used as src in the above dhcp discovery.

At 2nd stage the client sends a dhcp request and receives a dhcp acknowledge from the dhcp server.

This 2nd stage can be avoided when you use "rapid deployment" in the dhcp server. Then only the discovery/offer occurs.

Original Poster1 point · 9 days ago

I think dirty option number one was excactly what i had in mind from the beginning. Just wasnt sure it would work.

Thanks - i will give it a shot.

I dont think option twto would work as the switch at the site requires an IP adress for the interface to be able to setup DHCP relaying, thus requiring an extra IP that is not available in the /30 subnet i have been handed by the ISP.

What you can do in that 2nd option is to have the same vlan for 2 of the interfaces (the one for your VPN and your ISP) and then configure an vlan-interface on this vlan in your L3-switch. This way the switch can use dhcp relay to force the request to your RPI.

Note that the vlan-interface doesnt need to be within that /30, you can mix ipranges in the same vlan perfectly fine (but its often a bad practice but in your situation its one of the few options left).

Original Poster1 point · 9 days ago

Thank you for all the nice ghetto hacks you have suggested.
I will give some of them a try.

Certs? I don't need no stinking certs
1 point · 8 days ago

Just get the unit pre-configured in your cloud / ASG / whatever it's called, and have a user plug the RED into a DHCP-capable connection literally anywhere before it goes to their (presumably isolated) site.

Hell, you could plug it in once at your office LAN (as long as the RED has sufficient connectivity there to hit the ASG / cloud), just to allow it to pull the static IP config into the unit and reboot. Then shut it off and send it out.

You're making this way more complicated than it needs to be, at least according to what I can find from Sophos.

Original Poster2 points · 8 days ago · edited 8 days ago

Nope, wont work. It will need to be able to pull an WAN IP adress from DHCP at the remote location. Other than that, you are correct, and that is how i do it before shipping them.

EDIT: Sorry, i was too fast here.
I just looked at the link to the Sophos community page. And it does indeed indicate it would be possible to configure a static IP for one of the WAN interfaces. I will have to look at this again. Thanks for the heads up!

Certs? I don't need no stinking certs
1 point · 8 days ago

No problem. Like I said, I deal with a nearly identical conundrum with Velocloud Edge boxes. They are the same idea - pure cloud configuration, meant for morons end-users to just plug in and go.

However, the Velocloud Edges can support static WAN config... it just becomes tricky if the only WAN link at a site is static and you hadn't pre-configured the unit with that before shipping it out. I've used a bunch of different techniques to get around this though, so I know your pain. ;)

Certs? I don't need no stinking certs
1 point · 8 days ago

Sorry OP, but your Sophos RED box can use a static IP just fine.

It simply needs DHCP available at first boot, one single time in order to pull in the static IP config off "the cloud". I have the same behavior with Velocloud Edge boxes when I send them out to a site and haven't pre-loaded any config. (OTOH, Velocloud provides a nice way around this if needed, but I'm getting off topic)

https://community.sophos.com/products/unified-threat-management/f/remote-ethernet-device-red/57232/red-and-static-ip

That site should explain how you can solve this...

Community Details

121k

Subscribers

516

Online

###Enterprise Networking Routers, switches and firewalls. Network blogs, news and network management articles. Cisco, Juniper, Brocade and more all welcome.

Create Post

r/networking Rules

1.
Rule #1: No Home Networking.
2.
Rule #2: No Certification Brain Dumps / Cheating.
3.
Rule #3: No BlogSpam / Traffic re-direction.
4.
Rule #4: No Low Quality Posts.
5.
Rule #5: No Early Career Advice.
6.
Rule #6: Educational Questions must show effort.
Cookies help us deliver our Services. By using our Services or clicking I agree, you agree to our use of cookies. Learn More.