Issues talking to routes learned through OSPF.

[bshiers]

I have a Fortinet 60C running the most recent firmware available for it.  I have setup OSPF to a Cisco 2821 router in my lab.  OSPF comes up and I exchange routes, however I am unable to communicate from my LAN to the learned routes.  The fortinet will pass them no issues.  here is the pertinent config: 

edit "internal" set vdom "root" set ip 192.168.7.254 255.255.255.0 set allowaccess ping https ssh http fgfm capwap set type physical set snmp-index 6

config router access-list edit "OSPF_List" config rule edit 1 set prefix 192.168.48.0 255.255.255.0 set exact-match enable next end next end

config router ospf set distance-external 105 set distance-inter-area 100 set default-information-originate always set router-id 192.168.7.254 config area edit 0.0.0.0 set authentication md5 next end config ospf-interface edit "Internal_OSPF_Interface" set interface "internal" set authentication md5 set md5-key 1 "ENC eTcVX9pm00rCTASSzXmuPpA5KZZU" set dead-interval 40 set hello-interval 10 next end config network edit 1 set prefix 192.168.7.0 255.255.255.0 next end config redistribute "connected" set status enable end config redistribute "static" set status enable end config redistribute "rip" end config redistribute "bgp" end config redistribute "isis" end

get router info ospf route C 192.168.7.0/24 [1] is directly connected, internal, Area 0.0.0.0 O 192.168.48.0/24 [2] via 192.168.7.2, internal, Area 0.0.0.0 O 192.168.49.0/24 [2] via 192.168.7.2, internal, Area 0.0.0.0

From the fortinet: 

execute ping 192.168.48.1 PING 192.168.48.1 (192.168.48.1): 56 data bytes 64 bytes from 192.168.48.1: icmp_seq=2 ttl=255 time=10.7 ms 64 bytes from 192.168.48.1: icmp_seq=3 ttl=255 time=0.5 ms

I traceroute from a PC on the 192.168.7.x block as I can't ping 192.168.48.1: 

Brandons-iMac:~ brandon$ traceroute 192.168.48.1 traceroute to 192.168.48.1 (192.168.48.1), 64 hops max, 52 byte packets 1 192.168.7.254 (192.168.7.254) 0.655 ms 0.468 ms 0.400 ms 2 216.67.149.25 (216.67.149.25) 22.135 ms 15.943 ms 15.826 ms

It hits the forinet and routes out my default WAN gateway instead of my LAN/Internal interface:

From the Cisco I can ping the internal interface on the fortinet:

Border-Router#ping Protocol [ip]: Target IP address: 192.168.7.254 Repeat count [5]: Datagram size [100]: Timeout in seconds [2]: Extended commands : y Source address or interface: 192.168.48.1 Type of service [0]: Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes : Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.7.254, timeout is 2 seconds: Packet sent with a source address of 192.168.48.1 !!!!!

I can't ping the PC, which does allow PING from the LAN:

Border-Router#ping Protocol [ip]: Target IP address: 19 %Error opening t[link]ftp://255.255.255.255/network-confg[/link] (Timed out)2.168. *Mar 28 12:11:56.787: %SYS-4-CONFIG_RESOLVE_FAILURE: System config parse from (t[link]ftp://255.255.255.255/network-confg)[/link] failed7.119 Repeat count [5]: Datagram size [100]: Timeout in seconds [2]: Extended commands : y Source address or interface: 192.168.48.1 Type of service [0]: Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes : Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.7.119, timeout is 2 seconds: Packet sent with a source address of 192.168.48.1 ....

Here's the config on the Cisco: 

interface GigabitEthernet0/0 description to HomeLan ip address 192.168.7.2 255.255.255.0 ip ospf authentication message-digest ip ospf message-digest-key 1 md5 44Bottles!12 duplex auto speed auto ! interface GigabitEthernet0/1 description to Lab ip address 192.168.49.1 255.255.255.0 secondary ip address 192.168.48.1 255.255.255.0 duplex auto speed auto ! router ospf 1 router-id 192.168.7.2 redistribute connected subnets network 192.168.48.0 0.0.0.255 area 0 network 192.168.49.0 0.0.0.255 area 0 network 0.0.0.0 255.255.255.255 area 0

Any thoughts?  I'm sure it's something simple I'm missing and I can't find it!  I can talk to/from the fortinet to the routes learned on Gig0/1 via OSPF but I can't find my issue.  I did allow a rule to allow passing from internal to internal to both the netblocks on Gig0/1.  

[Toshi_Esumi]

Try adding deny policy for those internal subnets (192.168.48.0/24 and 49/24) toward the internet interface and move it to the top of policies. So that the FG never try that path when OSPF with Cisco is down. I'm suspecting the PC has been sending packets toward the internal subnets before the FG has learned routes, and a session(s) is established toward the internet following the default route.

[bshiers]

Toshi,

Thanks for the suggestion. I just tried it and the rule is catching traffic however I'm not getting anwhere with the block now: 

--- 192.168.48.1 ping statistics --- 15 packets transmitted, 0 packets received, 100.0% packet loss Brandons-iMac:~ brandon$ traceroute 192.168.48.1 traceroute to 192.168.48.1 (192.168.48.1), 64 hops max, 52 byte packets 1 * * *

[emnoc]

cli cmd Diag debug  flow is your friend. Also are you 100% sure that the internal 102.168.7.x is being seen in the cisco OSPF database?

Your problems sounds like the redistributed inside networks are not carried or a fwpolicy rule is not set to allow. But looking at the  networks and what you provided the  topology does not make any sense.

Are the local PCs on same  network of "internal" ? or have I misread this? if they are, than I do NOT see how  this would work since the  PC will most like try to   hit the cisco directly.

Can you draw a  topology map of the interfaces ( inside /external/etc....)

So that the FG never try that path when OSPF with Cisco is down

Remember  fwpolicy does not  DICTATE  routing , route lookups comes 1st, and  b4 we even  attempt to match a fwpolicy.ID

ken

[bshiers]

Ken,

Attached is a topology picture (poorly drawn, yes).  The Cisco sits behind the internal interface on the Fortinet, yes.  I'm trying to keep all this traffic local on my lan, it's for a LAB.  Yes the PC and Internal IP and one interface of the cisco are on the same subnet.  The IP's I'm trying to reach are on another subnet and another physical interface on the Cisco.  

[pyy]

Hello, I believe that this is normal behaviour as the client matches to a current session with NAT enabled.

You can follow 2 different paths 1. Add a static route for the network 192.168.48.0/24 (or any other) with Distance 200 pointing blackhole. ("diag sys session clear" after the change)

2. Change the default Session behaviour to drop and create a new session when routes are changed.

Best Regards Pyy

[bshiers]

Pyy,

By blackhole, what do you mean?  Just set the gateway to 127.0.0.1 or something?

[bshiers]

Pyy,

I just tried option 1 and I still cannot ping the 192.168.48.1 IP on the 2nd ethernet interface on my Cisco router, although the Fortinet has leared it via OSPF.  

[bshiers]

Oddly enough I reconfigured this and connected the Cisco the the DMZ on a different network.  After that and adding firewall rules I was able to ping from the router secondary subnets to my LAN subnet but not the other way around.  I had to add a policy route from my LAN block to my DMZ for the blocks in question to get 2 way traffic working.