On Mon, Jul 15, 2019 at 11:33:45PM -0700, BSD user wrote:
>
>
> 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}
This rule is perfectly fine.
> 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'
The problem here is that AS 64515 wants to match any part of the ASPATH
for AS 64515. Which is not there and so this rule never matches.
You can write this rule either as:
'allow to 169.254.169.254 prefix xxx.xxx.xxx.141/32'
or
'allow to AS 64515 prefix xxx.xxx.xxx.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?
Normally it is enought to limit the rule to the prefixes you want to
announce. So the first rule is just fine.
> 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.
That is a bit of a style question. In some cases using lo1 has benefits
(the IP will always be UP which can matter when you have multiple
interfaces). Using it on the only interface out would have the benefit
that you could use a default route that uses the public IP as source IP
for outgoing packets by default. (using 'route add default gateway
-ifa xxx.xxx.xxx.141')
In your case I guess neither matters so you can decide what you like
better.
--
:wq Claudio
