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
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
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
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
PCNSE
NSE
StrongSwan
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 ?
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
PCNSE
NSE
StrongSwan
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
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
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1519 | |
1019 | |
749 | |
443 | |
209 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.