Screen OS

I have a ISG-1000 running ScreenOS, and have been having some strange issues with regard to DHCP relay.

 

We currently are testing with three VLAN subinterfaces on an aggregated interface (aggregate1 = eth1/1-eth1/3). 

 

VLAN1: DMZ Network A (10.1.16.1/20)

VLAN2: Trusted Network (10.1.32.1/20)

VLAN3: DMZ Network B (10.1.48.1/20)

 

The DHCP Server is a MS DHCP server on the trusted network (10.1.32.10), and is configured with the proper scopes for each of the VLANS.  The ISG is configured for DHCP Relay on the aggregate1.1 and aggregate1.3 subinterfaces.  I know that firewall rules must also be configured to pass DHCP packets.  For this I have tried Any/Any/DHCP-Relay service rules from DMZ->Trusted, Trusted->DMZ, and both, and the client still is unable to recieve a proper address.

 

I have packet captured both on the server side and on the client side in VLAN3.  The funny thing is that there appears to be more DHCP packets on the server side of the ISG than on the VLAN3 side.  I am not particulary familiar with the protocol request structure of a DHCP transaction, but it seems that some packets sent by the server are not making it through the firewall.  I am seeing lots of NACK responses from the server and retried requests from the client.

 

I need to regather the captures, save them and I can post them here to get help.  Appreciate your thoughts.

 

#Relay
#DHCP
#ISG
#ISG-1000
#AGGREGATE
#vlan

Hey there

 

I don't think that is supported. Take a look at this KB on the Juniper site:

http://kb.juniper.net/KB12376

 

You can run the debugs to see if you are seeing the same error messages. If you see "packet dropped for self but not interested", I think its a limitation on the FW.

 

Thanks!

That makes sense.  That does describe exactly what I'm doing.  I will restructure the intrerfaces to remove tagging from the trusted interface.  Can you help point me in the right direction to be able to view theose debug messages?  I am a bit of a noob with this hardware, but am making my way around so far without problems.

 

Thanks!

Hi there

 

To run the debugs you can set up the filters as follows;

set ff src-ip X.X.X.X ip-proto 17 dst-port 68 (where X is the IP address of the DHCP Server)

set ff src-ip X.X.X.X ip-proto 17 src-port 68

debug flow basic

get db str ---> if you see some info coming in

--> Press Esc key to stop the debugs

 

review the output for the "get db str" and see if you have the same error msgs.

 

Run the following:

ssg5-isdn-wlan-> unset ff
invalid id

 

When you see "invalid id" you have removed all the filters you put in earlier.

"get ff " will tell you what filters you have currently for capturing debugs information.

 

This is another good link for your ref in case you need to run other debugs in future: 

http://forums.juniper.net/jnet/board/message?board.id=Firewalls&thread.id=2719

 

Please click on the kudos it this helps you! thanks!!

The KB article is a bit unclear as to which systems exactly are affected (looks to me its just VSYS).

 

Best to run some debugs to see what is happening. For more info about debugging, see this post. Set a flow-filter to filter the DHCP responses from the server and see what the firewall is doing with those. A debug dhcp might also be useful.

 

You'll need a policy from Trusted(dhcp server)->DMZ for DHCP-Relay (make sure the ports are correct).

 

 

You mentioned seeing many DHCP NACKs - normally you would only see those if your client requests an IP from the DHCP server that is outside of the defined scopes. This can happen if you move the client from one network to another, but then its just once. Maybe its a good idea to check the DHCP server config as well (are the correct networks defined and do they contain dhcp scopes?).

Hi

 

Some additional clarification on the KB. If both interfaces are tagged with different vlans, the dhcp relay will not work. It has nothing to do with the Vsys actually, that part was misleading.

Alright - Still banging my head over this one...

 

First of all, I ran the debug like WL asked.  I did not get any "packet dropped for self but not interested" responses, but to be safe I went ahead and restructured the trusted network so it has an interface of it's own (no VLAN tagging).  The other networks are still on an aggregated link, seperated into multiple VLAN tagged subinterfaces.

 

I also doublechecked the configuration of the scopes on the DHCP server to make sure I had not fat-fingered anything.  Everything there appears to be correct.

 

On the VLAN subinterface DHCP page, I have tried both with the 'Use DMZ Zone Interface as Source for VPN' box checked, and unchecked.  I am using no VPN tunnels in this config, so which way is the correct way to set this box?

 

The client (in VLAN 3) is now getting an IP address from the server, but it is an address from the Trusted network!  The funny thing is that when that box is checked, the packet captures on the server side have no relay agent IP's in the forwarded DHCP packets.  However, when the box is unchecked, the relay agent seems to pass both a version with the relay agent IP and one without it, which seems to cause all kinds of confusion and NACK responses.  Both eventually give an IP address to the client from the trusted network's scope.

 

I have compiled 'debug dhcp all', 'debug flow basic', and packet captures from both the client and dhcp server sides for both the checked and unchecked options.  I will post them here so you can have a look, each in it's own post (checked and unchecked) to keep things clear.  To me, it looks like the ISG is improperly forwarding the DHCP packets with regard to stamping the packet with it's relay agent IP, and therefore the DHCP server can't figure out what scope to use in it's offer.

This post is for the unchecked attachments.  Any attachments here were captured while the 'Use DMZ Zone Interface as Source IP for VPN' was unchecked.

This post is for the checked attachments.  Any attachments here were captured while the 'Use DMZ Zone Interface as Source IP for VPN' was checked.

Hi

 

I was looking at the captures for the "Unchecked" but there, it looks like there is some kind of loop. If you look at tha packet captures, you can see that there are 2 packets for each DHCP message:

Packet 21 and 22 : DHCP Request message

We are seeing one packet from the client MAC address and one from the relay agent. Is there some way for the client to broadcast to the DHCP Server?

We should only be seeing 1 packet from the FW (DHCP relay agent).

Whats the configuration setup on the FW?

That's what I was trying to say.

 

On the client side, you see four packets for each failed transaction.  A discover, offer, request, and NAK.  However, on the trusted side, the packets are multiplied.  It appears that the original packet is sent, as well as a packet which has been stamped with the 'Relay Agent IP Address'.  I believe that is why I am seeing all the NAK responses, because the multiple requests with the same transaction ID's are confusing the DHCP server.

 

I don't think there is anything set up that would allow the client to broadcast to the server without going through the ISG.  This is a test environment completely isolated with a single switch and manually defined VLANS for each port.

 

Do you want to see the ISG config?  What is the best way to collect the parts you need (and not the parts you shouldn't see)?

 

Thanks!

hi

 

I think "get conf | i dhcp" should help.

OK.  I found the source of the 'loop'.  The VLAN config on the switch was wrong, so whilt untagged traffic for the trusted network was going to the DHCP server, so was tagged traffic from VLAN 3.  I never set up the server's NIC to handle that tagged traffic, but it did anyway.

 

Now the client simply does not get an address (which I suppose is better than getting the wrong address.

 

Here's the DHCP config:

 

nsisg1000(M)-> get conf | i dhcp
set interface aggregate1.1 dhcp relay server-name "10.1.32.10"
set interface aggregate1.1 dhcp relay service
set interface aggregate1.3 dhcp relay server-name "10.1.32.10"
set interface aggregate1.3 dhcp relay service
set interface aggregate1.4 dhcp relay server-name "10.1.32.10"
set interface aggregate1.4 dhcp relay service
set interface aggregate1.5 dhcp relay server-name "10.1.32.10"
set interface aggregate1.5 dhcp relay service
set policy id 1 name "DHCP Relay" from "Trust" to "DMZ"  "Any" "Any" "DHCP-Relay
" permit
nsisg1000(M)->

 

FYI, the policy shown is the only traffic policy that currently exists.

I forgot to point out what is happening packet wise:

 

From the Client Side, all I see now is DHCP discovery requests from the client.

On the Server Side, I see the that a DHCP discover packet is directed at the DHCP server with the newly added Relay Agent IP, then a DHCP offer comes back from the server to the Relay Agent's IP, having the correct IP scope selected.

 

However, that offer packet never seems to makes it back to the client's VLAN.

Hi

 

Which interface is the client residing on?

VLAN3: DMZ Network B (10.1.48.1/20)

 

I guess this is the network you are having the client on?

So is it correct to say

 

Trust / DMZ Network B are both trying to get DHCP ip from the DMZ Network A side? DHCP Server is on the DMZ Network A? Sorry what is the IP Address of the Server?

 

So Trust gets IP fine but DMZ Network B is still not getting an IP?

Networks

 

Eth 1/1: Trusted (no longer a VLAN as far as Juniper is concerned): (10.1.32.1/20) 

Eth 1/2-1/3:  Aggregated Link with tagged VLAN subinterfaces 

     VLAN1: DMZ Network A (10.1.16.1/20)

     VLAN3: DMZ Network B (10.1.48.1/20)

 

Client is on VLAN 3 

DHCP Server is on the Trusted network (server IP is 10.1.32.10)

 

Clients on trusetd network recieve DHCP properly, but clients on VLAN 1 or 3 (the relayed requests) are not recieving responses.

For giggles, here are the new captures.  I am working off the assumption that the 'Use DMZ Zone Interface as Source IP for VPN' is supposed to remain unchecked for my environment.

Hi there

 

Could you take a look at the capture you uploaded? Doesn't look like the right one... ...

 

Try to run the debugs:

cl db

get ff (check to see if there is any filter)

>unset ff ( if you need to remove filters)

 

set ff src-ip 10.1.32.10 ip-proto 17

set ff dst-ip 10.1.32.10 ip-proto 17

 

debug flow basic

 

Press Esc to stop debugs

get db str

 

Prev debugs did not show anything useful at all. Lets run another capture and see if there is anything.

 

Quite a bit more information than last time in this debug.  Hopefully somehting interesting...

 

I updated the captures in my last post with the correct one - forgot to put the files in the .zip.  Oops. 😉

There are those 'packet dropped: for self but not interested' messages in there.  That's strange because only one of the interfaces involved in the exchange (the VLAN3) is a tagged interface.  The trusted is interface is a pure interface.

Yar, that means the interface is not recognizing the response for the DHCP packet that should be sent back to vlan 3. Which Screen OS are you using?

I am on 6.1.0r4.0.

Hmm I think its better that you open a JTAC case, it looks like there is some issue. 😞

Honestly, I'm just glad I'm not going nuts.  It seemed like it should have been working!?!?

 

Thanks a bunch for your help.  I will get a new case opened.

So JTAC was able to find the problem.  I had the interfaces set to NAT.  For some reason I thought that NAT would automatically only occur when passing to a public interface, and not between trust and DMZ interfaces.  However, the NAT was causing the returning DHCP offer to not be recognized properly.  I switched the interfaces to route mode and that seems to have taken care of the problem for now.  That is how I actually wanted it to act, so I will simply need to apply NAT to any outgoing policies that go to the public interfaces.  Just thought I would report back here in case anyone else has a similar problem!

 

Take care!