On 7/14/19 11:24 PM, Claudio Jeker wrote:
On Sun, Jul 14, 2019 at 07:28:29PM -0700, BSD user wrote:
On 7/14/19 12:52 AM, Denis Fondras wrote:
On Sat, Jul 13, 2019 at 09:44:28PM -0700, BSD user wrote:
Hello,
My apologies for sending this email multiple times.
I was so mortified by Tutanota's awful text formatting that I
created a new mail account that supported IMAP so that I could load
it up in Thunderbird with text only mode enabled.
Once again, my apologies for my rookie mistake choosing Tutanota for
use on an international mailing list such as this one. I hope you
guys will give me one more chance.
My (hopefully) unmangled message is below.
You did not include which version you are running, I'll assume this is
6.5. It seems you do not have any filter, OpenBGPD denies everything
by default.
Thanks for the reply Denis. You were right, I was missing my allow
rules. After setting "allow from any AS 64515" and "allow to any" rules,
everything started working. I was able to get IPv6 working as well
without a hitch.
Are there any other filter rules I should be setting to secure my BGP
deployment? I'm on a private ASN assigned to me by Vultr. This is my
first forray into BGP land, so any advice or tips would be much
appreciated.
Ideally you want to limit the filters to only announce what you really
need to announce to prevent leaking of prefixes because of a
missconfiguration. Also what is Vultr sending you via BGP? Depending on
that you may be able to limit the input as well.
I guess in this simple setup it does not matter to have simple allow
filters since this bgpd instance is not connected to the default free zone
and so there is less risk of leaking or receiving leaked routes. In
general if your BGP setup has more than one external neighbor you need to
take care of your filters to make sure that you don't leak updates from
one neighbor to the other.
Thanks for the reply Claudio!
You were right, my "allow from" rule was unnecessary, Vultr doesn't
appear to be sending me anything.
I managed to get my "allow to" rule tightened up to look like this:
allow to any prefix {xxx.xxx.xxx.141/32 2001:xxxx:xxxx:xxxx::/64}
I tried tightening the rule down further to restrict to Vultr's upstream
AS and IP addresses like so:
'allow to 169.254.169.254 AS 64515 prefix 140.82.0.141/32'
Unfortunately the rule doesn't work properly as my prefixes immediately
become unpingable after loading that rule. I'm probably missing
something obvious. Any suggestions on how to tighten down the rule further?
My final question is concerning assigning prefixes to interfaces. Is it
best practice to assign the addresses to something like 'lo1' loopback
interface, or should assigning it as an alias on an egress interface
suffice? I tried and they both seem to work.
Thanks
