Skip to main content
JamieSLH
JamieSLH
New Member
July 24, 2018
Solved

Setting up a Remote Admin (and/or LDAP) on a firewall on a different subnet from the AD...

  • July 24, 2018
  • 1 reply
  • 4633 views

(Noobie Alert !! - forgive any non-standard terminology...)

 

We have 10 FortiGate or FortiWiFi installations across the country, 9 of which are hooked into the 'main' network thru IPSec tunnels.  We also have a Primary AD server, and two clone AD's at 3 of the ten locations.

 

On the locations that have an AD server directly attached (on the same subnet) to a Firewall, I have setup an LDAP, and Remote Users as an ADMINs...   On the firewalls without AD servers directly attached, I cannot setup an LDAP poiinting to our primary AD server, which is on a different subnet, and so cannot setup Remote Users...

 

Everytime our policy dictates that it's time to change a password, for the ADMINs, it needs to be changed in the AD, and on each of the 7 firewalls without an AD server.  Needless to say, this leads to much complaining, and occasionally to a screwup where someone needs to signon to the Master Admin to reset another Admin's password...

 

How do I go about allowing an LDAP entry for an AD on a different subnet (but in the same network)?

 

Thanks

Jamie

    Best answer by Toshi_Esumi

    Everybody had the first time.

    If your server is directly connected, let's say 192.168.1.100/24, on one of LAN ports (interface IP:192.168.1.1), you don't need a policy for any authentication requests initiate by the FGT because it's initiated by itself. And since it's directly connected, you don't need any additional route because 192.168.1.0/24 is a connected route and it's already in the routing-table.

     

    For other remote FGT authentication requests, the remote FGT needs to have a VPN to the first FGT at least for 192.168.1.0/24 and a route for the subnet pointing to the tunnel interface. But no need for policy on the remote FGT side. However, the first FGT needs to have at least one policy in VPN -> the LAN port direction to allow the auth request to come in and reach the 192.168.1.100. The first FGT remembers the return path in a session but you generally need VPN <- the LAN port policy for all the other traffic from 192.168.1.0/24. 

    The source IP (destination IP for returning packet) should have the tunnel interface IP, let's say you use 10.100.1.2 for a remote FGT side and 10.100.1.1 for the first FGT, then 10.100.1.2 is the source IP (unless you configured a different IP via CLI. It doesn't seem to be available in GUI). But it's already in the first FGT's routing-table because you must have configured it as "remote-ip" for the VPN interface. So you don't have to worry about routing.

     

    So, it's just about routing and you can test the reachability by pinging to the server from the remote FGT specifying the source like "execute ping-o source 10.100.1.2", then "execute ping 192.168.1.100". You should be able to get responses as long as the server is allowing pinging.

     

    I looked for any cook books but so far I couldn't find anything for this situation. But quite simple. It's just around routing.

     

     

     

    1 reply

    Toshi_Esumi
    SuperUser
    Toshi_Esumi
    SuperUser
    July 24, 2018

    As long as the route is there remote auth servers can be anywhere. That's how we set up our RADIUS and TACACS servers for all FGTs around the nation. None of them have a directly connected auth server.

    JamieSLH
    JamieSLHAuthor
    New Member
    July 24, 2018

    Toshi : Can you direct me to a particular KB or recipe I can look at ? - my lack of knowledge is embarassing...

     

    Here's what I tried that didn't work - On the remote firewall I set an address pointing to the local AD server, thought I'd set a policy route, and added the AD Server as an additional destination on the policy pointing to the tunnel, and then tried to set up the LDAP server.  It wouldn't connect.  (probably obviously to you non-noobs)

     

    Thanks

    Toshi_Esumi
    SuperUser
    Toshi_EsumiAnswer
    SuperUser
    July 24, 2018

    Everybody had the first time.

    If your server is directly connected, let's say 192.168.1.100/24, on one of LAN ports (interface IP:192.168.1.1), you don't need a policy for any authentication requests initiate by the FGT because it's initiated by itself. And since it's directly connected, you don't need any additional route because 192.168.1.0/24 is a connected route and it's already in the routing-table.

     

    For other remote FGT authentication requests, the remote FGT needs to have a VPN to the first FGT at least for 192.168.1.0/24 and a route for the subnet pointing to the tunnel interface. But no need for policy on the remote FGT side. However, the first FGT needs to have at least one policy in VPN -> the LAN port direction to allow the auth request to come in and reach the 192.168.1.100. The first FGT remembers the return path in a session but you generally need VPN <- the LAN port policy for all the other traffic from 192.168.1.0/24. 

    The source IP (destination IP for returning packet) should have the tunnel interface IP, let's say you use 10.100.1.2 for a remote FGT side and 10.100.1.1 for the first FGT, then 10.100.1.2 is the source IP (unless you configured a different IP via CLI. It doesn't seem to be available in GUI). But it's already in the first FGT's routing-table because you must have configured it as "remote-ip" for the VPN interface. So you don't have to worry about routing.

     

    So, it's just about routing and you can test the reachability by pinging to the server from the remote FGT specifying the source like "execute ping-o source 10.100.1.2", then "execute ping 192.168.1.100". You should be able to get responses as long as the server is allowing pinging.

     

    I looked for any cook books but so far I couldn't find anything for this situation. But quite simple. It's just around routing.

     

     

     

    Terms & ConditionsAccessibility statement