ADVPN-Spoke-Spoke Communication

Forum|Forum|8 years ago
February 13, 2018
3 replies
5946 views

Hello Fellas,

In my own lab I was able to hit (able to worked) ADVPN setup using this link "http://cookbook.fortinet.com/configuring-advpn-in-fortios-5-4-dynamic-hub-and-spoke-vpns/". My spokes (remote sites) able to ping the Head Office (HUB) and vise-versa, spoke-spoke able to ping as well.

Few question in mind, how do I control let say spoke (site A) could NOT able to ping this specific spoke (site B)?

Regards,

Toshi_Esumi

SuperUser

I didn't know they added this feature with 5.4 until now. At a glance at the cookbook, I don't like this design with multiple reasons:

- We have many reasons to use FWs to control traffic:allowed or denied, or connect or not connect explicitly. This is opposite.

- When you add another node connected only from one remote,this would brreak. Why don't use eBGP instead if you use non-public ASN range? iBGP route-reflector is necessary if you're using your own public ASN.

Anyway, the direct answer to your question would be just placing a deny policy between source and destination subnets and ADVPN<->ADVPN interface combo BEFORE/AVOVE the allow("accept") policy. That would block whatever you want to block.

FullmoonAuthor

New Member

Thanks Toshi for your response. That's my initial idea too.Though im out from my office to extend my simulation, would you mind where do I apply the deny rule is it in the HUB fw policy?

ede_pfau

SuperUser

Spoke to spoke with automatic shortcuts cry for problems if you want to keep control on it. The whole idea behind ADVPN is that you allow dynamic shortcuts spoke to spoke to relieve the hub's burden. It's not about economizing on security.

That said, you cannot fully control sp2sp traffic on the hub alone; you need to provide policies on the spokes.

Sign up

Login with SSO

Login to the community

Login with SSO