Pulse Secure formerly SSL VPN
Showing results for 
Search instead for 
Do you mean 
Reply
Recognized Expert
Posts: 420
Registered: ‎03-24-2008
0

Re: 802.1Q tagged VLANs on the internal port

Ives -

 

Have you tried it with the default VLAN for the IVS set to the VLAN you are assigning?  I think the SA sends all management traffic, which might include the DHCP request, over the default VLAN.  This would also mean, however, that the authentication, logging, archiving data, etc., from the IVS would also be put on that VLAN.  Not sure if this configuration would work for you...

Contributor
Posts: 32
Registered: ‎07-08-2008
0

Re: 802.1Q tagged VLANs on the internal port

Are you running the recent firmware? The previous version I had, 5.5R2 don't have a VLAN tab, but when I upgraded to 6.1R2 it has the VLAN tab that enable us to create 2 or more VLANs etc, though I'm having a hard time to enable tagging on the Internal Port to support those VLANs. Anyone?

 

Thanks

Recognized Expert
Posts: 420
Registered: ‎03-24-2008
0

Re: 802.1Q tagged VLANs on the internal port

I'm on 6.0R5 with a hotfix.  It must be that VLANs were added to the basic set in 6.1.

 

You don't have to do anything special to tell the SA to do 802.1q trunking.  All you have to do is to define the VLANs.  You do have to configure your switch to let it know this is a trunk port rather than an access port.

Contributor
Posts: 13
Registered: ‎09-16-2008
0

Re: 802.1Q tagged VLANs on the internal port

Kenlars -

 

We have a SA 6500 with 6.2R2-1 in test. We dont have IVS license.

 

We have the default VLAN with two others VLAN configured on the internal interface. Effectively the DHCP request work fine if we assign the default VLAN with a role.

 

Thanks

Yves

Regular Visitor
Posts: 5
Registered: ‎09-22-2008
0

Re: 802.1Q tagged VLANs on the internal port

Hi Yves,

 

I have came across the same problem myself. I am in a position where I need to assign static IP to users connecting via NC and want to reserve addresses for them to 'ease' the management.

 

I have set the role in its own vlan but a capture on my DHCP server shows the source address as being the default internal IP address, not the VLAN the NC profile belongs to.

 

Did you have any luck or are you going to just use the default internal IP address rather than vlanning it off.

 

Cheers,

Gareth

Recognized Expert
Posts: 420
Registered: ‎03-24-2008
0

Re: 802.1Q tagged VLANs on the internal port

Gareth -

 

Have you set the VLAN/Source IP under the General tab for the role to select the desired VLAN?

 

Ken

Highlighted
Regular Visitor
Posts: 5
Registered: ‎09-22-2008
0

Re: 802.1Q tagged VLANs on the internal port

Hi Ken,

 

Yep I have selected that and like Yves, when I use the IVE to issue DHCP it is cool but when I point it to my DHCP server, the DHCP server receives packets with the source address of the default internal vlan.

 

After the post I actually tried adding a static route for my DHCP server in the NC VLAN route table but unfortunately did not work, DHCP server still received DHCP request from default internal vlan.

 

Cheers,

Gareth

Recognized Expert
Posts: 420
Registered: ‎03-24-2008

Re: 802.1Q tagged VLANs on the internal port

Gareth -

 

I recommend you open a JTAC case.  It would seem to me that any DHCP request should be sent from the SA's address on the specified VLAN for the role, and that clearly is not occurring.  In the admin manual, there is a section on using a shared DHCP server for multiple IVSs, with some way for the DHCP server to differentiate between the requests.  So you might be able to do what you want to do if you implement IVSs.  I'd see this as a workaround, not as a permanent correction to the problem.

 

I'm seeing the same behavior with an autoproxy PAC file I have which uses the source IP address of the client to make decisions about the correct proxy.  When the SA is creating the instantproxy.pac file, it clearly fetches the PAC file from the source address of the default VLAN for the IVS instead of the source address of the VLAN assigned to the role.  I've found a workaround for this - the PAC file allows the source IP to be hard-coded in the URL instead of getting it from the client address - but I don't think I should have to use this workaround.

Contributor
Posts: 11
Registered: ‎09-26-2008
0

Re: 802.1Q tagged VLANs on the internal port

Hi,

 

I opened a case for this even I have the IVS feature enabled but I do not want to make a new IVS for every VLAN which we want to enable NC and have DHCP server enabled. =)

 

Br,

Pasi

Contributor
Posts: 13
Registered: ‎09-16-2008
0

Re: 802.1Q tagged VLANs on the internal port

Hi,

 

We will open a JCARE case for this even. we want to know if it's a bug or if it's not supported.

 

Thanks,

Yves

Contributor
Posts: 11
Registered: ‎09-26-2008
0

Re: 802.1Q tagged VLANs on the internal port

After months of waiting.. =)

From JTAC:

--cut--

It is working as implemented - We use the default VLAN IP as the gateway IP address in the DHCP request.



I would recommend you to contact your sales manager to raise a ENHANSMENT REQUEST [ ER]. Since the product is working as designed, the feature thatyou want can be obtained only by a enhansment request.

--cut--
Trusted Contributor
Posts: 192
Registered: ‎10-02-2008
0

Re: 802.1Q tagged VLANs on the internal port

[ Edited ]

All,

 

From what I have gathered from this incredibly long thread is that you are trying to use the physical interface (which cannot be tagged) and sub-interfaces (which can be tagged).  I'm going to talk Foundry since that's the evil I know.  On a Foundry, there is what is called dual-mode.  On the physical interface of the switch, you configure it for dual-mode, and tell the interface for what default VLAN you want untagged traffic dropped into.  All other traffic will be tagged (802.1q) and will be dropped into the proper VLAN.

 

Example:

 

conf t

 int e 1

 dual-mode 111

 

vlan 112

 tag e 1

vlan 113

 tag e 1

vlan 111

 untag e 1 

 

 

Someone in the world of Crisco, can you confirm what I'm saying:

 

If a dot1q trunk receives a tagged frame on the native vlan, it drops it.

When a cisco trunk port receives untagged frames it forwards them to the native vlan #1 by default

So, if you want the native VLAN to be something other than 1, you can change the default VLAN, but this does not move STP or other Crisco things from VLAN 1.

Message Edited by Munpe_Q on 11-17-2008 05:54 PM
Message Edited by Munpe_Q on 11-17-2008 05:54 PM
-=Q
Contributor
Posts: 42
Registered: ‎05-15-2008
0

Re: 802.1Q tagged VLANs on the internal port

On a Catalyst, I believe that if untagged traffic is received, then it is considered to be that of the "native vlan" (by default 1) and is global.

Recognized Expert
Posts: 420
Registered: ‎03-24-2008
0

Re: 802.1Q tagged VLANs on the internal port

[ Edited ]

That is correct.  I use this configuration on Catalysts, and all untagged traffic leaving the SA is put on the default VLAN on the turnk port of the switch.

 

Don't know if this suggestion will be useful, but I had some success getting Juniper to move on a "working as designed" issue that I had.  I told them - through the JTAC engineer and my local SE - that if it was "working as designed", then it was "designed as stupid".  I think that applies here too.  If a role has its traffic assigned to a VLAN, and uses DHCP, it makes no sense to send the DHCP request out as untagged traffic.  Or - at the least - you should have the option for the DHCP traffic to be sent on the VLAN.

 

Ken

Message Edited by kenlars on 11-18-2008 09:41 AM
Trusted Contributor
Posts: 192
Registered: ‎10-02-2008
0

Re: 802.1Q tagged VLANs on the internal port

OK, so what I said was accurate then.  It will send it to the default VLAN.  The default VLAN on Crisco can be changed, but that doesn't move things like STP or Crisco proprietary stuff over, that still remains on VLAN 1.

 

Word. 

-=Q
New User
Posts: 1
Registered: ‎01-27-2009
0

Re: 802.1Q tagged VLANs on the internal port

So, any news about this issue with external DHCP servers? I'm in contact with the JTAC but luck yet.

 

Regards.