Screen OS

 View Only
last person joined: 6 months ago 

This is a legacy community with limited Juniper monitoring.
Expand all | Collapse all

DHCP Relay on a ISG-1000

  • 1.  DHCP Relay on a ISG-1000

    Posted 01-13-2009 11:27

    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


  • 2.  RE: DHCP Relay on a ISG-1000

    Posted 01-13-2009 11:42

    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!

    Message Edited by WL on 01-13-2009 11:44 AM


  • 3.  RE: DHCP Relay on a ISG-1000

    Posted 01-13-2009 11:53

    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!



  • 4.  RE: DHCP Relay on a ISG-1000

    Posted 01-13-2009 12:05

    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! Smiley Happy thanks!!

    Message Edited by WL on 01-13-2009 12:07 PM


  • 5.  RE: DHCP Relay on a ISG-1000

    Posted 01-13-2009 12:16

    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?).



  • 6.  RE: DHCP Relay on a ISG-1000

    Posted 01-13-2009 12:30

    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.



  • 7.  RE: DHCP Relay on a ISG-1000

    Posted 01-14-2009 09:06

    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.

    Message Edited by Vorcht on 01-14-2009 09:35 AM


  • 8.  RE: DHCP Relay on a ISG-1000

    Posted 01-14-2009 09:11
    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.

    Attachment(s)

    txt
    debug dhcp all.txt   1 KB 1 version
    txt
    debug flow basic.txt   7 KB 1 version
    zip
    unchecked_captures.zip   11 KB 1 version


  • 9.  RE: DHCP Relay on a ISG-1000

    Posted 01-14-2009 09:13
    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.

    Attachment(s)

    txt
    bacic flow.txt   693 B 1 version
    zip
    checked_captures.zip   1 KB 1 version
    txt
    debug dhcp all.txt   1 KB 1 version


  • 10.  RE: DHCP Relay on a ISG-1000

    Posted 01-14-2009 10:11

    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?

    Message Edited by WL on 01-14-2009 10:18 AM


  • 11.  RE: DHCP Relay on a ISG-1000

    Posted 01-14-2009 10:26

    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!



  • 12.  RE: DHCP Relay on a ISG-1000

    Posted 01-14-2009 10:43

    hi

     

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

    Message Edited by WL on 01-14-2009 11:03 AM


  • 13.  RE: DHCP Relay on a ISG-1000

    Posted 01-14-2009 12:38

    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.



  • 14.  RE: DHCP Relay on a ISG-1000

    Posted 01-14-2009 12:44

    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.



  • 15.  RE: DHCP Relay on a ISG-1000

    Posted 01-14-2009 13:07

    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?

    Message Edited by WL on 01-14-2009 02:01 PM


  • 16.  RE: DHCP Relay on a ISG-1000

    Posted 01-14-2009 13:18

    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.

    Message Edited by Vorcht on 01-14-2009 02:17 PM


  • 17.  RE: DHCP Relay on a ISG-1000

    Posted 01-14-2009 13:26
      |   view attached
    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.
    Message Edited by Vorcht on 01-14-2009 03:15 PM

    Attachment(s)

    zip
    Updated_capture.zip   840 B 1 version


  • 18.  RE: DHCP Relay on a ISG-1000

    Posted 01-14-2009 14:12

    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.

     

    Message Edited by WL on 01-14-2009 02:12 PM


  • 19.  RE: DHCP Relay on a ISG-1000

    Posted 01-14-2009 14:30
      |   view attached

    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. 😉

    Attachment(s)

    txt
    debug flow basic.txt   10 KB 1 version


  • 20.  RE: DHCP Relay on a ISG-1000

    Posted 01-14-2009 14:33
    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.


  • 21.  RE: DHCP Relay on a ISG-1000

    Posted 01-14-2009 14:40
    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?


  • 22.  RE: DHCP Relay on a ISG-1000

    Posted 01-14-2009 14:45

    I am on 6.1.0r4.0.



  • 23.  RE: DHCP Relay on a ISG-1000

    Posted 01-14-2009 15:02
    Hmm I think its better that you open a JTAC case, it looks like there is some issue. 😞


  • 24.  RE: DHCP Relay on a ISG-1000

    Posted 01-14-2009 15:05

    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.



  • 25.  RE: DHCP Relay on a ISG-1000
    Best Answer

    Posted 01-16-2009 10:03

    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!