OSPF filtering routes between areas

[sam91]

Hi there,

I have a really frustrating problem with OSPF ...

I have two ASAs on the left within the area 1.1.1.1 and a vpn tunnel endpoint with the ip 192.168.200.1/32

I set up OSPF on both ASAs to redistribute the connected VPN client. That works as I want it to work. Actually it works too good...

The FortiGate in the middle shall be a ABR between the two areas.

But I don't want R2 in area 0.0.0.0 to have every /32 route for every VPN client. So I tried to set up a filter-list on the FortiGate to block the prefix 192.168.200.1/32 route (yep, already that desperate to keep it simple).

But no matter what I do the /32 route keeps popping up on R2 

Here's the output from the FortiGate:

FortiGate-VM64-KVM # get router info routing-table all

Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
       O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default

C 192.168.1.0/24 is directly connected, port2
O 192.168.2.0/24 [110/11] via 192.168.1.2, port2, 00:18:14
C 192.168.3.0/24 is directly connected, port1
S 192.168.200.0/24 [10/0] via 192.168.3.1, port1
O E2 192.168.200.1/32 [110/20] via 192.168.3.3, port1, 00:18:13

config router prefix-list
    edit "filterarea0"
        config rule
            edit 1
                set action deny
                set prefix 192.168.200.1 255.255.255.255
                unset ge
                unset le
            next
        end
    next
end


config router ospf
    set router-id 192.168.1.1
    config area
        edit 1.1.1.1
            config filter-list
                edit 1
                    set list "filterarea0"
                next
                edit 2
                    set list "filterarea0"
                    set direction in
                next
            end
        next
        edit 0.0.0.0
            config filter-list
                edit 1
                    set list "filterarea0"
                next
                edit 2
                    set list "filterarea0"
                    set direction in
                next
            end
        next
    end
    config ospf-interface
        edit "Internal"
            set interface "port2"
            set dead-interval 40
            set hello-interval 10
        next
        edit "ASA-side"
            set interface "port1"
            set dead-interval 40
            set hello-interval 10
        next
    end
    config network
        edit 1
            set prefix 192.168.3.0 255.255.255.0
            set area 1.1.1.1
        next
        edit 2
            set prefix 192.168.1.0 255.255.255.0
        next
    end
    config redistribute "connected"
    end
    config redistribute "static"
        set status enable
    end
    config redistribute "rip"
    end
    config redistribute "bgp"
    end
    config redistribute "isis"
    end
end

And yes, i know the filter shouldn't be applied everywhere. But as I mentioned, I'm REALLY desperate...

Looking forward to hear from you :)

~Sam

[Antonio_Milanese]

Hello,

simplified note on filtering:

Filtering Type 3 LSAs on ABRs

Filtering Type 5 LSAs on ASBRs

your ASAs acts as ASBRs

Your vpn client routes are external routes type 5 lsa E2 routes for the sake of precision..so prefix filtering does not work for type 5 (in/out) on FGT..

anyway since your intent it's just to summarize the 192.168.200.0/24 why do no use the logical "summary-address" way ?

btw IIRC setting advertise to disable to area range should have the same effect of "area range not-advertise" on cisco world "filtering lsa 5" inter-area.

Regards,

Antonio

[emnoc]

I think you can do it. ABR should be able to filter E2  based on a few means you could  set the area as  NSSA  and filter the type7

Do as mention above and   summary a  /32 

Any one of these approach would be ideal in your  issues. Since your taling intra-area routes which are  distributed as E2. I be you  could  distribute the vpn 192.168.200.0/24 as connected route but it would be done via  a hacked up loopback or some other weird method. This will allow you to inject the 192.168.200.x as  ospf-area  route and not a External-Type2

just my two cts

[sam91]

Hi guys, thanks for your quick reply. I managed to grasp the ASBR concept now.

I also realized I wasn't quite detailed in what I wanted to do :(

I got two individual ASAs. A VPN client can connect either to one or another but will get the same ip address.

So the ASA in charge of handling the VPN connection should advertise the hostroute for that client towards the FortiGate.

One ASA should be the "default VPN gateway" and the FortiGate should have a summary route for 192.168.200.0/24 to it. The other ASA should propagate the individual host routes to the FortiGate.

The FortiGate however should only redistribute the summary route 192.168.200.0/24 to the router R2.

If I do a summary on the ASAs the FortiGate only learns the summary route. But it will need the individual host routes as well.

If I don't do a summary the R2 router will learn the host routes.

Should I try using a NSSA area for 1.1.1.1 ?

[emnoc]

Can you   draft a   topology? Your explanation is not clear as to what your asking.

But  in the cisco ASA config I believe you might want to look at the RRU injection  in the crypto map. This throws the  host route  when and only of the  client is attached. I used this in earlier  9.x code when we had deploy numerous  vpn gw and re-used the same  pool across them.

( example )

crypto map rwvpnclients 10 ipsec-isakmp set peer x.x.x.x reverse-route static crypto ipsec transform-set Trans1 esp-aes esp-sha-hmac match address 110

Will that work for you?

 http://socpuppet.blogspot...-asa-vpn-and-ospf.html

[Antonio_Milanese]

Hello Sam,

umm if I understand your intention it seems to me a bit over-complicated design to handle with single OSPF instance and a regular area...maybe declaring ASA links as P2P and FA filtering at FGT you can "filter" those RRI to get on backbone..but if you can accomodate the NSSA conversion it's way to go IMHO so your FGT it's now the translator and you can filter on "rigenerated" LSA7->LSA5 and even advertise a summary route for the area....

but at this point I wonder... is it really a constraint to redistribute from ASAs (RRI or not) using OSPF?

why do not use another IGP like IS-IS or even ripv2 so your FGT it's the only A(S)BR for that area and you have all control between redistributed routes ?

Regards,

Antonio

[sam91]

Hi @all,

thank you for your replies and sorry for not getting back earlier.

After numerous attempts on getting it to work with OSPF I'm now stuck with RIPv2 which works perfectly fine in my use-case and is plain simple. I use it in conjunction with distribute-list inbound on the FG and redistributing a static route for summarization towards the backbone.

Cheers,

Saskia