> Sent: Monday, July 15, 2019 at 11:52 PM
> From: "Claudio Jeker" <cje...@diehard.n-r-g.com>
> To: "BSD user" <fleshisat...@bsdmail.com>
> Cc: misc@openbsd.org
> Subject: Re: Moving from Bird to OpenBGPD
>
> 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
>
Hi Claudio,
Thanks so much for clarifying things for me, I really appreciate it. I now feel
I have a much better understanding of OpenBGPD (and the BGP protocol in
general).
I was able to get my filter rule down to one line covering both IPv4 and IPv6:
allow to AS 64515 prefix {xxx.xxx.xxx.141/32 2001:xxxx:xxxx:xxxx::/64}
Thanks for the advice regarding filtering rules by ip address and AS, as well
as prefix interface assignment. I ended up assigning the public ip as an alias
on my egress interface so I could NAT outgoing traffic from my httpd server
cluster using that address.
I must say, I love the 'depend on' feature. I have failover between redundant
machines using carp working perfectly.
Cheers
PS
Hopefully this email arrives to you unmangled. My trial period with mail.com
ended and I can no longer use IMAP/Thunderbird as it's apparently a "premium
feature". I hope the mail.com web clients text mode works properly.
