Juniper SRX, Virtual Routers and DHCP Relay

A couple of weeks ago, I started to implement virtual routers in my SRX300. The reason being a new external subnet that needed to route to a specific security zone. Using the default VR only wouldn't work because of the (single) default route.

Implementing it was fairly easy. The trouble began this week;

Wireless controller not accessible
Client with weird behaviour
etc.

In my network, I have 1 DHCP server serving multiple internal subnets. The (basic) DHCP relay configuration was:

set forwarding-options dhcp-relay maximum-hop-count 10
set forwarding-options dhcp-relay client-response-ttl 10
set forwarding-options dhcp-relay server-group DHCP_Server 192.168.x.x
set forwarding-options dhcp-relay active-server-group DHCP_Server
set forwarding-options dhcp-relay group clients active-server-group DHCP_Server
set forwarding-options dhcp-relay group clients interface ge-0/0/0.1
set forwarding-options dhcp-relay group clients interface ge-0/0/0.20
set forwarding-options dhcp-relay group clients interface ge-0/0/0.30
set forwarding-options dhcp-relay group clients interface ge-0/0/0.200

Turns out that this stops to function when implementing Virtual Routers. Something I forgot to adjust. And since the DHCP scope on my server was set to a lease-time of 14 days.... That means that problems tend to introduce themselves after a couple of days.....

Anyway, after changing the DHCP relay configuration to include the correct Virtual Router name (DEFAULT) everything worked just fine.

set routing-instances DEFAULT forwarding-options dhcp-relay maximum-hop-count 10
set routing-instances DEFAULT forwarding-options dhcp-relay client-response-ttl 10
set routing-instances DEFAULT forwarding-options dhcp-relay server-group DHCP_Server 192.168.x.x
set routing-instances DEFAULT forwarding-options dhcp-relay active-server-group DHCP_Server
set routing-instances DEFAULT forwarding-options dhcp-relay group clients active-server-group DHCP_Server
set routing-instances DEFAULT forwarding-options dhcp-relay group clients interface ge-0/0/0.1
set routing-instances DEFAULT forwarding-options dhcp-relay group clients interface ge-0/0/0.20
set routing-instances DEFAULT forwarding-options dhcp-relay group clients interface ge-0/0/0.30
set routing-instances DEFAULT forwarding-options dhcp-relay group clients interface ge-0/0/0.200

So. DHCP is a bit like DNS. Both have timers (TTL and lease-time) that might bite you in the butt.

Posted on June 10, 2018 by Willem and filed under Annoying, Junos, Security and tagged DHCP relay VR virtual router.

Juniper SRX and DHCP Client Challenge

A couple of years ago I wrote a post about a dual ISP config with a Juniper SRX firewall. At the time I ran into some challenges regarding the DHCP client functionality of the SRX. For some reason it couldn't get a lease from the Ziggo ISP DHCP servers. Any other DHCP server on my local network worked just fine. Since I created a work-around at the time (by using an additional NAT router and static IP addresses) I didn't give it much thought.... Until last week.

Last week I ran into a networking challenge that kinda freaked me out. For some reason my Apple TV wouldn't connect to my NAS, but it could connect to the Internet. For some reason my Apple TV got a public IP address while it was located on my internal network. The public IP address was completely unknown to me. So, WTF was giving my Apple TV a public IP address?

VPN and Resolving Issues on OS X

We have a lab which we can access by using a VPN (Cisco ASA and Cisco AnyConnect). This setup has a so-called split DNS configuration, which means that only resources in the lab are accessed through the VPN tunnel. Regular Internet traffic uses my local DSL connection.

At my house I (like most folks) rely on DHCP for providing me with IP address, gateway and DNS servers. My local subnet uses 192.168.10.1 for DNS and 192.168.10.254 is my default gateway. So my clients are in the same subnet as my DNS server (directly-connected).

All these things considered I should be able to browse the Internet while I have a VPN running. Well, that's where you're wrong.

OS X Yosemite DHCP Server

This week I re-installed my Mac Mini server at home. It still ran Snow Leopard, and it was time to start with a clean slate. So after a couple of hours of pondering if I had forgotten to backup something, I started with a clean install of OS X Yosemite (10.10).

Everything went smooth, until I started using the DHCP service that comes with the Server App add-on.

My server uses 802.1q (VLAN-tagging) to connect several different VLAN's which I feed into several Virtual Machines. So I also use several DHCP Scopes for those segments.
The IP addresses for these scopes are all in the 192.168-range (class C subnets), so when I created the scopes I had to go through a simple wizard in the Server App. I just had to fill-in the blanks (very user friendly), and OS X did the rest.

Upon testing I ran into the weirdest behaviour on my network. Getting connectivity with a device took a very long time, and when the device got an IP address, it was from a different network (???)> So it couldn't communicate across the network.

At first I began to wonder if I had mixed up the VLAN names and tags, but those were correct. After an hour of troubleshooting (more and more DHCP clients were failing in the network), I found the problem;

When you create a scope Apple will assign a default subnet mask (255.255.0.0). I guess I should have seen it, but I didn't.

After I changed the subnet mask in the DHCP scopes everything went back to normal.

Lesson learned: Don't rely on wizards and other user-friendly stuff.

Posted on December 31, 2014 by Willem and filed under Apple, Annoying, Tips'n Tricks and tagged DHCP OS X Yosemity Server Scopes Class C.

Apple OSX DHCP Server Challenges

The last week, I've been experimenting with the Juniper Mobility System Software (MSS) in conjunction with two Juniper/Trapeze Access Points (type WLA522E). The MSS software is a Wireless LAN Controller (WLC) with manages the Access Points, and like so many Juniper Product; it can run in a virtual machine.

For the AP's to boot / connect to the network they need some basic information about where to find the WLC from which they receive their wireless settings. This can be done through DNS, or through DHCP. The first uses specific DNS records, and the latter uses DHCP Options (option 43 to be precise). I wanted to use the latter (which is a bit more challenging).