Messages

Problem solved!

It was fat-fingering on my part. Sorry about the noise.

I reconfigured from scratch with more paranoid filtering rules and to my surprise, my end started sending my v6 network to my ISP who appropriately has now propagated out to the rest of the world.

So the good news is that - at least for simple cases like mine - OPNSense is perfectly capable of exchanging v4/v6 routes with other BGP instances.

And thanks to all those who responded. Some of you may or may not have been on the right track, but every post gave me a question to answer and an opportunity to check whether what I was doing was right or not.

Edit: Just to be clear: it wasn't the more paranoid filtering rules that solved the problem. It was that the whole process of re-entering the config serendipitously removed my previous typos that were present in the initial config.

Also confusing: your inbound BGP defines your outbound IP traffic. Your outbound BGP defines your inbound IP traffic. Then there's path prepend/append, MED, ... it's fun and pretty simply once you get to it. Simple and reliable.

Right. In this case there is no path prepend/append, MED, communities or any other complexity. It's a straightforward route exchange, but my OPNSense instance is not sending the v6 network for reasons I don't yet understand. But that's the beauty of Open Source. I have a chance to dig into the relevant programs and code if necessary.

Shouldnt the ISP advertise them for you since you get the specific networks routed by the ISP to you via BGP and you just install a default route back?

No. That's the whole point of BGP. I tell my ISP what networks I have at my end and they in turn tell their peers and upstreams.

My network assignments come from my regional registry (not my ISP) so strictly speaking my ISP doesn't even know what networks I'll advertise until they show up in their BGP session. (In practice ISPs do know for filtering and security reasons).

As for accepting the full routing table vs the default routes, that should not affect what I send upstream. Again, this is strictly my ISP telling me which routes they accept.

As I said in the OP, this is about as simple as you can get when it comes to route exchanges over BGP. I'm trying to send one v4/24 and one v6/48 and my ISP is sending defaults for both v4 and v6. Everything is working in both directions *except* my sending of the  v6/48.

I saw it at a customer recently who peered IPv6 and IPv4 over BGP with default routes by the ISP, but I don't remember the specific configuration.

Essentially it should work.

Thanks. Do you recall whether it was a two-way exchange of routes?

I am getting default routes from the ISP correctly for both ipv4 and ipv6. It's me sending my specific networks up to the ISP that is not working for v6 (v4 is fine).

So the distinction between sending and receiving is important in this regard.

Hmm. Perhaps the first question I should ask is, is anyone successfully advertising ipv6 via BGP?

I have a very simple setup on 25.1.3 - it consists of a single /24 ipv4 and a single /48 ipv6 I'm trying to advertise to my ISP.

I have both v4 and v6 CIDRs in the BGP -> General -> Network field and I have the ISP's v4 and v6 Neighbours configured.

Both the v4 and v6 sessions to the ISP come up but only the v4 session sends the /24 network. No matter what I tweak I cannot get the v6 session to advertise the /48 network.

I have tried toggling "Network Import-Check" and tried various prefix lists and route maps. Nothing I toggle seems to cause the /48 to be sent to the remote end. I have also tried advertising just the v6 address, but no difference.

Not that it should matter, but both the v4 and v6 networks are configured on an active interface.

Other information:

1. The ISP is sending down default routes on the v4 and v6 session so the sessions are definitely up and running.

2. I'm tcpdumping the BGP traffic to confirm what is going on.

3. The /48 *is* showing up in the Routing -> Diagnostics -> ipv6 Routing Table but with 'x' under Valid and Best.

4. Oddly the v6 default route received is not showing up under Routing -> Diagnostics -> ipv6 Routing Table but the v4 default route
received *is* showing up in the corresponding ipv4 Routing Table.

I can't believe I'm the first person to advertise ipv6 this way, so I presume there is some trick or other that I've missed.

If neither the v4 or the v6 network were being sent, I'd be happy assuming I've messed up, but that v4 is working makes it harder to understand why v6 is not.

Thoughts or experiences anyone?

im trying to achieve to block every thing i mentioned on my first post.

Right. Which included "and so on".

In any event, your list is so expansive as to effectively cover a large and hugely diverse range of applications and services, thus why I was asking for something more along the line of categorization or generalization that might be applicable.

Even just looking at your specific huge list, you do realise that these sort of Internet giants are spinning up new IP addresses daily as they deploy and expand their networks.

Ok, after hours of fideling im now frustrated and need a break.

After i found out, that zenarmor works, but sadly not to 100%

I'm not sure what you're trying to achieve exactly, but ultimately if you let an App access its own servers on the wider internet, then ultimately you wont be able to block them doing DNS lookups if they use their own servers to do so, which some do!

While many DOH clients use public DNS servers such as Google, which makes it easier to firewall their well known addresses; nothing stops apps from running their own DOH servers on their own infrastructure. And by design DOH traffic is indistinguishable from regular web traffic.

So I don't think a 100% solution is possible unless you completely firewall all of the apps servers and thus disable the app completely.

for example "server.domain.test" to "172.17.17.1", and not anything else.

Do you mean constrain the request or the answer? Sounds like you mean the answer coming back.

If you know what the answer is going to be (say it's always 172.17.17.1) then you can over-ride the host/domain with a local instance of unbound.

But if you want to change the answer by, e.g., removing additional A RRs or removing all AAAA RRs, then that's not possible with firewall rules as you need to modify the DNS packet by, amongst other things, changing the "answer count" and shuffling up any OPT RRs that may be at the end of the response.

In short, you'll probably have to create/find a plugin which re-writes the DNS answer to satisfy this requirement.

A case of asymmetric routing, possibly?

I have also found this to be a problem with other protocols. In particular IMAP and SUBMISSION when I had those services running on a DMZ network with a server that had a NIC on both LANs.

In my case the session dropped at 64K bytes rather than an elapsed time, but I presume this too is related to asymmetric state tracking - or lack thereof.

It's a very subtle problem and hard to solve, so someone should give pmhausen's quote some stars or pin it or something so it stays fresh in our minds.

Now I want to buy a quad or dual Ethernet card for my machine I dont know what standards or types it supports, please let me know what parameters should I consider to choose an Ethernet (NIC) card/adapter.

Pretty much anything that is supported by Freebsd13.1 as defined in https://www.freebsd.org/releases/13.1R/hardware/#support

The Intel PRO/1000 series is popular and well regard, but of course there are other good vendors.

If you've installed OPNSense or have access to a Freebsd 13 system, you could read the man pages for igc, em or ix as they list the supported chipsets. From there you can search for cards that suit your needs.

You can also search the popular online stores for quad cards and pfSense, since it runs the same OS.

You can run a pi-hole for your DNS. It gives a breakdown between A and AAAA lookups

Thanks for the suggestion Bart, I probably should have been clearer that I need to know the ratios in terms of packets and bytes in and out.

Counting DNS queries is going to be too much of an approximation since one A query might result in a 1GB youtube video while another AAAA query might be a 1KB tweet. DNS queries also don't tell me anything about outbound vs inbound ratios, e.g.

So, good idea, but I really am after byte and packet counts in both directions for both protocols.

I'm looking for an easy way to capture the ratio of ipv4 traffic vs ipv6 traffic. Ultimately I want to plot these values over time to watch the trend.

At first I thought I was on to something useful when I found Firewall->Diagnostics->Statistics->Interfaces.

But oddly, the packet counts and the bytes counts are the same values. Not sure whether this is a bug or a limitation of the particular NICs on this platform. See attached image (if I attached it correctly).

Then I thought I could makes some firewall rules with "Pass,not quick, no state" for each of the v4/v6 in/out combinations on the WAN interface, but a) the Insights display showed very low counts and b) it's not clear to me how many of the default rules are passing the traffic before it gets to those "counter" rules.

So, any suggestions on how I can get packet and bytes counts in and out of the WAN interface for both protocols?

PS. I did have a fairly extensive search around the forum and the net, and nothing obvious showed up.