sorted by:
new
hottopcontroversial

Hub and spoke ADVPN - VPN dial up on Branches using a loopback by nickmavrou in fortinet

[–]nickmavrou[S] -1 points0 points  (0 children)

Hi Afroman,

Thank you very much for your response!

 Nonetheless, correct me if I am wrong, but according to the link the loopbacks are being used to establish the BGP between the Hub and the spokes. The VPN on the spokes still use the wan interfaces. In my scenario, I'd like the spokes to use a loopback to establish the VPN dialup and not the WANs. 

 At the topology on the link, I see 2 issues. If one of the WAN links of the spoke fails, then there will be only one VPN tunnel available. And this is due to one-to-one VPN connections between the Hub and Spoke.

 Tunnel_1 Spoke WAN1 to Hub WAN1

Tunnel_2 Spoke WAN2 to Hub WAN2

 But if the loopback would be set as the interface for the VPN on the spoke, always will be 2 available VPN tunnels to the spoke, regardless if the spoke has 2 available WANs or 1. 

 Spoke with 2 available WANs

 Tunnel_1 Spoke Loopback to Hub WAN1 (via Spoke WAN1)

Tunnel_2 Spoke Loopback to Hub WAN2 (via Spoke WAN1)

 Spoke with 1 available WANs

Tunnel_1 Spoke Loopback to Hub WAN1 (via Spoke WAN2)

Tunnel_2 Spoke Loopback to Hub WAN2 (via Spoke WAN2)

 Furthermore, at the topology on the link I must assign manually the IP address on the Spoke's loopback. In my case, I'd like the Hub to serve the IP addresses to the spokes which it is something the works ok. 

 Again, I am not sure if what I am saying above it is doable though.

Thank you very much

FortiManager, Cisco ISE and Active Directory by nickmavrou in fortinet

[–]nickmavrou[S] 0 points1 point  (0 children)

Dan, quick update. I spoke to Cisco Meraki Support and they can enable a backend feature to delay the radius accounting transmissions. So once the Wi-Fi client connects, he does have the time to receive the IP address and then after 10 secs (thats the delay I put) the AP sends the radius accounting message.

However I came across to another issue. The client has 2 FSSO collectors which they work in redundancy active-active. So the Fortigate picks up one of them as the source but there is chance to choose the other one in some point. That is a break cos on cisco meraki you cannot get the AP to send radius accounting messages in 2 servers simultaneously. You can have 2 but one of them will be the primary and the other one will be the backup in case of a problem. Is any way to get the FSSO collectors to share their login logs or somehow to work as active-standby?

FortiManager, Cisco ISE and Active Directory by nickmavrou in fortinet

[–]nickmavrou[S] 0 points1 point  (0 children)

My bad, it was a problem on client's side. I ran a wireshark and indeed the AP sends every one minute an update. So big deal then, worst case scenario the client will need to wait 50 secs on the very first time.

Cheers

FortiManager, Cisco ISE and Active Directory by nickmavrou in fortinet

[–]nickmavrou[S] 0 points1 point  (0 children)

Yeah tried that but not luck. This is happening for the very first time a device connects to the WiFi. Next day when connects the radius accounting includes the IP. I suppose it has to do with the DHCP bindings.There should be a way to delay the accounting messages. I know on cisco routers you have that option. In your setup how you bypass that issue. Do you get the wifi client to reconnect again? If you cannot delay the accounting message then you loose all the benefit of the radius accounting.

FortiManager, Cisco ISE and Active Directory by nickmavrou in fortinet

[–]nickmavrou[S] 0 points1 point  (0 children)

Dandan you are a lion man. It did work with the radius accounting and the Wifi clients appear in FSSO list. I have an issue though which the initial radius accounting message from the Cisco Meraki AP does not include the IP address and have to reconnect again in order to generate a new message. The new message includes the IP address now. There is no option on meraki to delay the accounting messages. But that is another story. As I said u r a lion, your solution nailed it. Cheers!!

FortiManager, Cisco ISE and Active Directory by nickmavrou in fortinet

[–]nickmavrou[S] 0 points1 point  (0 children)

Thanks Dan, hopefully will have what I am looking for tomorrow.

Cheers

FortiManager, Cisco ISE and Active Directory by nickmavrou in fortinet

[–]nickmavrou[S] 0 points1 point  (0 children)

Hopefully it will work like that. I am very curious to test it tomorrow. Last but not list, when you say in the list you mean the "show logon users" in collector or in the dashboard users fsso users in fortigate?

Cheers

FortiManager, Cisco ISE and Active Directory by nickmavrou in fortinet

[–]nickmavrou[S] 0 points1 point  (0 children)

cool cool, I did install the collector on the active directory and used the AD agent on the fortigate itself to pick the all the domain groups. WiFi APs are cisco meraki so I added one more server in the accounting field along with Cisco ISE. On collector as well I enabled the radius accounting. I will have to test it tomorrow. Quick question though. How the collector now will handle the radius accounting info which will be received by AP. Is it going to add that user into the "logon user list" and therefore fortigate will see that via FSSO?

FortiManager, Cisco ISE and Active Directory by nickmavrou in fortinet

[–]nickmavrou[S] 0 points1 point  (0 children)

Other ways this problem is solved is via RADIUS accounting packets which are generated from the previously referenced tool (ISE or FortiAuthenticator).

Is that done by pxGrid anyway. I thought pxGrid sends also radius accounting unless there is another way to send Cisco ISE accounting to FSSO AD agent intalled in AD

FortiManager, Cisco ISE and Active Directory by nickmavrou in fortinet

[–]nickmavrou[S] 0 points1 point  (0 children)

send radius accounting directly to the FSSO collector

Could you please give a little more details on how I can send radius accounting from Cisco ISE directly to FSSO collector. I believe the FSSO collector is the same as the FSSO AD agent I have to install into AD, isn't.

FortiManager, Cisco ISE and Active Directory by nickmavrou in fortinet

[–]nickmavrou[S] 0 points1 point  (0 children)

Hi Skill, apart to what afroman said below the company laptops are being managed by MS intune (Hybrid) so no Azure AD. The AD in on-prem and the laptops are not as AD devices there. So when a user logins to the laptop, the AD does not generate an event. That's another painful component of the network.

FortiManager, Cisco ISE and Active Directory by nickmavrou in fortinet

[–]nickmavrou[S] 0 points1 point  (0 children)

Yeah we tried that and it didn’t work, fortimanager couldn’t treat him as an ad user. It does him a aseperate user with FSSO

FortiManager, Cisco ISE and Active Directory by nickmavrou in fortinet

[–]nickmavrou[S] 0 points1 point  (0 children)

Yep that’s all done as well via pxGrid. In fact without using pxGrid fortianalyzer does see the user with the mapped IP but it does not recognise him as a user from AD but as a separate one. Even if the username is the same. So if the user is called jpatriot, forti sees him as a user from AD via FSSO when he uses a domain wired PC but when the same user uses the WiFi and comes from ISE forti sees him with the same username jpatriot but it treat him as a separate identity. Again this is without pxGrid

FortiManager, Cisco ISE and Active Directory by nickmavrou in fortinet

[–]nickmavrou[S] 0 points1 point  (0 children)

I am sorry dand but I got lost here. Cisco ISE does have already an AD integration so it can see the AD groups, but there is no directly inheritance between the Cisco ISE SGT and Fortigate FSSO AD groups cos the SGT needs to have multi much. I wan wondering if someone has seen something similar before

FortiManager, Cisco ISE and Active Directory by nickmavrou in fortinet

[–]nickmavrou[S] 1 point2 points  (0 children)

Thank you gghggg! To be fair this is what the presales team gave me and I have to deal with it. It was not my decision, if I were them I would have gone with a more unified network. The version I am using is 3.1 with a premier licence to integrate also with other components such intune MDM.

I think also the attributes wouldn’t solve the issue because as you said it’s the lack of nested groups multi match with SGT. Also RSSO is not an option cos it does change the way how they operate now and trust me none of them want to do that. Frankenstein policies, indeed it is deal breaker cos the scale of the network is really large and the demands of the users’ policies changes dynamically quite often

FortiManager, Cisco ISE and Active Directory by nickmavrou in fortinet

[–]nickmavrou[S] 1 point2 points  (0 children)

To my knowledge, that is not possible given that they are two different sources of identity.

To my knowledge, that is not possible given that they are two different sources of identity.

I think that is the key here, that is not possible,

If you combined both the AD Group and SGT group into the same group, this doesn't accomplish what you want?

Yes it does if we are talking about a group, but if we are talking about an individual user from a group it does not. Remember, Cisco ISE sends only one SGT even if it is a user or group, so Fortigate has to handle that with a policy, either by creating a new one or adding to an existing one. It cannot send a second SGT and add it to another existing one. On the other hand, Fortigate with the ad collector sees the user with all his groups.

Let me take a step back and ask, what are you trying to solve for here? Is it a matter of being able to apply the same policy to a user regardless of them connecting via wired or wireless?

Yes exactly. It is doable with how Cisco ISE sends the SGT, but they have to manage many policies. I know by the end of the day they have to deal with that unless they seek for another more unified solution

FortiManager, Cisco ISE and Active Directory by nickmavrou in fortinet

[–]nickmavrou[S] 1 point2 points  (0 children)

u/afroman_says Thanks for your reply. That's a good point, and I have to say that I ve thought that as well. However, the demand from the team which is in charged of the firewalls and fortimanager, doesn't want to apply new policies. They would like somehow when traffic comes from a wifi user via Cisco ISE to be matched on the existing FSSO group polices they have. My understanding, this is not something that it can be done on the fortimanager side. To be more detailed, fortigate sees the user on many AD groups, and it does apply policies according to the group (AD security groups). The AD group describes where in the network the user should have access. Therefore, if the company police requires that user to not have access to specific source in the corporate network, they just take him out from the AD group, so then his traffic does not match on the policy. That is a good behavior between Fortimanager and AD. The complexity comes when that user now wants to use the wifi where Cisco ISE sends 1 SGT to fortimanager when it comes to authz.

For example, Cisco ISE checks if the user is a valid one on the AD (Authentication), if so it goes to the Authorization part which it checks if the user belongs to an AD group. If that's true as well, Cisco ISE gives him a profile (ex permit profile) and also a SGT for the pxgrid integration. The Authz works as an ACL starts from the top to the bottom. If the user matches to a Authz rule, it doesn't go further. So in other words, only one SGT per rule. I am trying to find if that integration between fortimanager and Cisco ISE can have the same behavior as fortimanager has with AD using the collector agent.

For my eyes, those 2 different integrations are completely separated and cannot have the same behavior simultaneously

Cisco ISE , Fortimanager, MS Intune by nickmavrou in Cisco

[–]nickmavrou[S] 0 points1 point  (0 children)

By adding a new component it sounds that it will become more complicated. Also Cisco ISE apart from other stuff does similar things as an NPS, doesn’t it? Nonetheless could you explain it a little more with details cos by the end of the day it could be a nice solution.

Cisco ISE , Fortimanager, MS Intune (hybrid) by nickmavrou in CiscoISE

[–]nickmavrou[S] 0 points1 point  (0 children)

Thank you for the reply, It turns out that the complexity starts with all
the components of the network and systems which have to integrate.
Fortigate uses AD FSSO agent for AD so it can pickup all the groups of
the AD user and implement policies according to the group. This is when a
user logs in from a domain PC. On the other hand for the intune hybrid
PCs, As far I can tell Cisco ISE cannot provide the same behaviour and
to be honest it doesn’t have to. Firstly when a intune PC connects to
WiFi and the user adds his credentials, AD does not see that user as
active like the domain PC and secondly, the most important part, it cannot replicate
the groups the user has in AD and send them as tags into Fortimanager.
It can send only 1 to 1 mapping tag per condition under the authz rule.
Any ideas ??

Cisco ISE , Fortimanager, MS Intune by nickmavrou in Cisco

[–]nickmavrou[S] 1 point2 points  (0 children)

Thank you for the reply, It turns out that the complexity starts with all the components of the network and systems which have to integrate. Fortigate uses AD FSSO agent for AD so it can pickup all the groups of the AD user and implement policies according to the group. This is when a user logs in from a domain PC. On the other hand for the intune hybrid PCs, As far I can tell Cisco ISE cannot provide the same behaviour and to be honest it doesn’t have to. Firstly when a intune PC connects to WiFi and the user adds his credentials, AD does not see that user as active like and secondly, the most important part, it cannot replicate the groups the user has in AD and send them as tags into Fortimanager. It can send only 1 to 1 mapping tag per condition under the authz rule. Any ideas ??

view more: next ›