Screen OS

Hi,

I'm having some issues with a SSG5 security device. I have a need to enable external DHCP (public IP from ISP) on a set-top-box in the internal network (the ISP recognizes the STB based on MAC address to enable certain features).

So far I have split the STB from the rest of the network using VLAN's. The issue is getting the DHCP working on the SSG5.

Current setup (public IP's are fake for security reasons):

Eth0/0 - Internet connection via modem - 76.25.4.81/18 - Untrust zone

Bgroup0 - Local network - 192.168.2.254/24 - Trust zone

Bgroup0.1 - Vlan tag 10 - 0.0.0.0/0 - Untrust zone

I added a policy to allow ping and dhcp relay services within the Untrust zone.

I figured this would allow the clients on vlan10 to get an IP through eth0/0.

Unfortunately this seems to be a no go, clients in the VLAN resort to 169.254.x.x range.

Next thing I tried was enabling DHCP relay on the VLAN using the DHCP server reported by eth0/0.

This requires setting an IP range on the subif, while I'm not sure which range the ISP is using.

So far this hasn't given any usable results, same 169.254.x.x range.

If all else fails I could sacrifice an ethernet port on the SSG5 and connect it to the VLAN directly. Then place it in a bgroup with eth0/0 to get switch functionality. Though it seems as if there should be a better solution to this...

Thanks for any input on this!

mvds

Why do you need to have public DHCP? Port-forwarding (VIP) would probably do what you need, which may be an easier option. Have you tried this?

Thank you for the idea.

However, I'm afraid that's not an option.

Allow me to clarify:

I have the same provider for internet and digital TV (using a STB). The STB requires access to the internet to enable certain 'interactivity' features, enable tv guide, unlock paying channels, etc...

To enable these features the ISP recognizes the STB based on it's MAC address. It's linked to my account so they can enable channels, track usage and what not.

As far as I know using a VIP will not expose the STB, instead it will still be hidden away inside the network. The ISP will be unaware of the STB sitting behind the Juniper box.

If I can somehow get the SSG5 to report the STB's MAC address using a mapped IP that might work...

---

@mvds wrote:

If I can somehow get the SSG5 to report the STB's MAC address using a mapped IP that might work...

---

Not possible on an SSG as far as I'm aware.

Do you need to be able to protect the STB with the SSG? If not, you could use your bgroup idea above. If you do need the STB to be protected, you'll need to run a couple of interfaces on the SSG in transparent (l2) mode. If you need the SSG to also get a public IP through DHCP (and the ISP allows you to get multiple IPs through DHCP), you could try the following:

1. Keep eth0/0 in l3 mode, getting its IP through DHCP.

2. Use eth0/1 (or bg0 containing eth0/1 or whatever) in l3 mode as your internal (LAN) interface.

3. Use (e.g.) eth0/2 in l2 mode as your STB's untrust interface.

4. Use eth0/3 in l2 mode as your STB's trust interface.

    (Note that this mixed l2/l3 mode is not officially supported by Juniper, but I've used it successfully in the past)

You'll need an external switch (or VLAN) to connect port eth0/0 and port eth0/2 to your ISP router. You should be able to get one IP assigned to the SSG (eth0/0) and one assigned to the STB (don't forget to permit DHCP traffic from your STB to your l2 untrust zone, and permit in whatever traffic your ISP needs to have to your STB, if applicable).

Spud, thank you for confirming this is not possible using an SSG.

I'll resort to the alternative solution then, quite similar to what you describe except I don't require the trust interface for the STB.

Current working setup:

I have 2 ports from the juniper connected to a VLAN capable switch:

- eth0/1, grouped in bgroup0 along with other trust interfaces.

- eth0/4, grouped in bgroup1 together with eth0/0 (the modem connection).

Since both eth0/4 and eth0/0 are in a bgroup, clients on eth0/4 will get an IP address through eth0/0 from the ISP (yes, the ISP allows me to use multiple IPs).

The switch is configured to connect VLAN 10 on the eth0/4 port, allowing me to expose virtually any device from the internal network. In this case the STB.

I was hoping to eliminate the extra connection between SSG and switch, but I guess the current setup will do.

---

@mvds wrote:

 

The switch is configured to connect VLAN 10 on the eth0/4 port, allowing me to expose virtually any device from the internal network. In this case the STB.

 

 

I was hoping to eliminate the extra connection between SSG and switch, but I guess the current setup will do.

---

Be aware that doing this means anything connected to eth0/4 is not firewalled from the internet, so I wouldn't recommend this method. Ports in a bgroup are treated as basic switch ports and frames are simply switched between member ports in the same bgroup without being inspected. If this is a concern, you should try the l3/l2 hybrid mode I mention.

By the way, a simpler way to do what you're currently doing (and eliminate the need for the second bgroup and second connection between the SSG and the switch) would be to simply create an untrusted VLAN on your switch (or just use your existing VLAN 10) and connect the ISP router, the SSG's untrust interface and any devices you want to be exposed directly to the internet (e.g. the STB) to this VLAN.

I'm aware the current configuration does not provide any security. At this point in time I'm only exposing the STB, which doesn't need it. If I decide to connect any other devices I'll definately look into the solution you proposed.

Nice idea to connect the modem directly to the VLAN.

I didn't think of connecting the juniper through the VLAN. That effectively eliminates the extra connection.

Guess I overlooked the obvious there. Thank you for pointing it out!

Another option would be to configure e0/4 with one of your public addresses in a /30 network inside your range.

Then use the second address for your host device.

You will need to check the "Ignore Subnet Conflict for Interfaces in This VRouter" on the virtual router to configure the second interface.

This interface can then be in untrust or another zone and have firewall rules active for traffic going to the host.