Configure fortigate for virtual IP with hsrp

[longwave]

Hi all, We have the following configuration for an existing network: Client | SWITCH +--Switch-port1---FW---Rp---Company +--Switch-port2--------Rs---network Where Rp is the principal router and Rs the secundary or backup router. The routers have a physical IP address each and one floating or virtual IP for in case of fail over. The default gateway for the clients is set to the virtual IP. Most probably, although I am not sure, the routers use HSRP / SSO of Cisco. These routers communicate through the switch. It is unknown how the current firewall is configured, as it is of another brand. We would like to replace for a Fortigate 200. I gave a factory reset to the Fortigate 200 enabled policies let pass all traffic to and from the internal and external interface, which connect to the switch and the principal router respectively. Then I plugged in the FG200 where the former firewall was and then client-pcs couldn' t get to the company network. What would I need to activate on the firewall or its interfaces? static mac addresses for the phyical IP addresses on the routers? allow to pass Layer 2 traffic on both the external as well as the internal interface? Thanks.

[emnoc]

Okay assumptions, we are assuming the firewall is a layer2 firewall. You should only need the src ( client network ) and destination network at minimum. Are you 100% sure that the 2 HSRP routers are configured correcly? and the clients are indeed using the VIP address and not real static interface ip_addrs? What I would do, is too down the standby router, place a policy for all of the client network space to ping the static and VIP address of the router. Make sure connectivity is granted. Than bring up the secondary router and conduct the same test.

[longwave]

Both firewalls are supposedly configured correctly, although I cannot see any configuration of them. They have the fysical addresses x.x.x.2 and x.x.x.3. The virtual IP is x.x.x.1 which is the default gateway for the network connected. It is confirmed the protocol is Cisco - hsrp. Configuring the FortiGate in the same setup as in the previous message won' t work for some reason I don' t know. In transparent mode, the 2 interfaces connected had l2forward enabled as well as stpforward enabled, for if necessary. The configuration wouldn' t work. Neither connecting the 2 routers to an interface each on the Fortigate with the same l2forward and/or stpforward enabled on those interfaces. Pinging from inside the network to servers on the outside shows that for some time response times are OK (1-2 ms) and then for a time they are quite long with a lowered ttl. After all I configured a VLAN in the switch for the router domain with the firewall in between to connect to the user network as follows: Client (connect to switch ports with VLAN-default) | SWITCH +--Switch-port1---VLAN-external---Rp---Company +--Switch-port2---VLAN-external---Rs---network +--Switch-port3---VLAN-external---FortiGate-external interface +--Switch-port4---VLAN-default----FortiGate-internal interface All ports indicated are set to UNTAGGED for their corresponding VLANs. No Vdoms are used in the FortiGate. For security on the external interface the floating MAC is configured with: config system mac-address-table edit <floating MAC> set interface external next end See also the article 11594 ' Transparent mode layer-2 Ethernet issues with 3rd party load balancing clusters' The floating mac was detected with ' diag ip arp list' . Look for the corresponding x.x.x.1 entry. It can also be seen in the switch ports.

[emnoc]

What I would do, is too down the standby router, place a policy for all of the client network space to ping the static and VIP address of the router. Make sure connectivity is granted. Than bring up the secondary router and conduct the same test.

Did you try the above? Btw ciso HSRP is not load-balancing at all. The HSRP active member is active ad the standby is just that, standing by. If you have access, a issurance of a cisco cli " show stand brief" , would show you who is active. If you have doubts on if HSRP is or is not configured, diag sniffer packet the wire and you should see the HSRP packets. If you don' t see any, than it could be GLBP or VRRP, both of which is supported by cisco routers/switches btw. I would rule out the standby for now, and make sure the active is working and then continue on with your investigation and trouble shooting. Also since HSRP needs adj to each other, the external VLAN should be shared between the 2 cisco IOS. So don' t plug their 2 interfaces up int the firewall directly unless you want more issues to contend with

[longwave]

That is what I did without having separated VLANs: disconnecting the secondary router made the traffic passing through fluently and happely. Once the secondary router was connected things went slow till loosing connectivity intermittently. In the switch port monitor the virtual MAC address was appearing on the port of the secondary router for some reason, while when both the principal and the secondary are operating, the virtual MAC + its IP should go to the primary. Configuring the VLAN worked well for me and for the moment I' ll stay with that. It would be interesting to know why connecting the 2 routers directly to the Fortigate interfaces will give me ' issues to contend with' . There must be something more profound beyond knowledge of what the Fortigate is doing internally.

[emnoc]

Probably because HSRP woould be blocked on the firewall interfaces. Unless you had a rule ( assumption here ) the multicast destination network for HSRP would be blocked at the external interfaces. I believe it' s all host or all router address (224.0.0.1 or 224.0.0.2 ) for the desitination. I' ve always placed any VRRP/HSRP devices on a vlan that' s shared with the firewall(s) interfaces and only seen weird things when running redundant firewalls unless the port where set for portfast.

[longwave]

There are 2 rules: internal --> external any host on both sides can access to any service external --> internal any host on both sides can access to any service No more than that. There is a document in the Fortigate knowledge base ' Configuration best practice and troubleshooting tips for a FortiGate in Transparent mode' docid 30087, that mentions forwarding hsrp traffic using static MAC entries for the virtual MAC used by hsrp. Furthermore there are not much references on how to configure that kind of traffic in the Fortigate manuals. Asynchronous routing wouldn' t be an option neither in this case (I guess, I never used it). For the record: the firmware used is 3.0 MR7 Patch10.

[emnoc]

So how is your bridge control list and what is it showing. diag netlin brctl list and the state of the HSRP peers ( cisco ) show stand " intfc" fwiw I never had to place a static entry for the virtual-mac on any transparent firewall that I have deployed. Are we 100% sure that the HSRP is configured and works correctly, before you place the firewall into the picture? I hate for you to troubleshoot the heck out of this and find the problem is at the HSRP routers. If you can set a temporay ip_address device, on the common wire for the HSRP pair and then fail or adjust the priority to cause a failover condition and make sure that it works 100% faultless. If that pass, than you can look deeper into the FGT setup. I worked with a providers that thought the HSRP peer where set right, and we battle them for 4 days, until they came out and indicated that the secondary side have zero routing. btw how we rectified that , was to have them place track statements for the next-hop interface state e.g interface Vlan234 description UPLINK telefonica to terremark/MIA Level3 ip address xx.77.2.252 255.255.255.0 no ip redirects ip route-cache flow standby 34 ip xx.77.2.254 standby 34 preempt standby 34 track " insert the interface here" FWIW: I' m also suspecting there' s another issues, the standby is set for preempt and failover to " active" , hence the vmac has migrated to the former stand-by device, which is now trying to be active. I really suspect, you have multiple HSRP configuration issues at hand or something hosed up on the secondary, and it has nothing todo with the FGTs. I would disable preempt and even run a debug stand event followed up with a term mon when failover or reconnecting the standby. if you can' t gain access to the pair, have the router-admin conduct the above and send you the results. one more thing, I' ve seen problems with HSRP and the need to enable portfast on cisco switchports that connects these paris. So you can do that if switchport portfast make sure you go back after troubleshooting and tighten up those rules ;) good luck