View Single Post
  #9   (View Single Post)  
Old 18th April 2016
Nivekg Nivekg is offline
Real Name: Kevin Guerra
kevingnet
 
Join Date: Apr 2016
Location: Santa Clara
Posts: 8
Default

Quote:
Originally Posted by jggimi View Post
I don't know who "most everybody" is, but what *you* need to do is configure *your* network topology to meet your requirements. And a bridge (combining physical Ethernets into a single Ethernet) with two distinct IP subnets adds no value, as you had depicted in your first post. If that's confusing, then step back, and consider what it is you want to accomplish by inserting OpenBSD between your Linux platform and your ISP's router. I assume its to eventually build a full PF configuration, for packet filtering or bandwidth shaping, or both. But only you know what it is you want to accomplish.
For example, you were already using NAT in your environment - your ISP's router (which is apparently integrated with the cable modem) provides you with the 192.168.0/24 subnet.

This is a subnet within a range of addresses that can only be used for private networks, and cannot be routed over the Internet. (There are uncounted millions of private networks using addresses in the 192.168/16 address range, and using NAT to reach the Internet.)

All of your devices on all of your networks, once you get them working -- will share a single Internet facing IP address through the ISP's router. Whether you keep NAT provisioned in PF, or not. (And yes, with both the ISP's router and your OpenBSD router deploying NAT, you would have two address translations for every packet between the Linux system and the Internet.)
You have been misinformed. Bridging, while sometimes used, is a relatively infrequently used tool. Packet forwarding is far more common. So, if you are reading 3rd party "how to" documents, and assuming these are common or best practices, that's often an incorrect assumption. Be very wary of anything you find on the Internet. Even things you find here on this forum. We're just users. Only official documentation (the OpenBSD FAQ, INSTALL.<arch> files, man pages, etc.) content is supported.

Most 3rd party how-to documents are written by newer users who may not have complete understanding of the process they are documenting, or the guides do not consider all possible use-cases, or the guides are out-of-date. Or some combination of the three.

I've written a few of these 3rd-party how-tos. One that I wrote for the OpenBSD Journal was reviewed by a half-dozen developer/editors before it was published, and yet it was out-of-date and no longer valid within a single year's time. OpenBSD evolves, and is a moving target.

Do 3rd party how-tos have value? Yes, *if* you read them with the understanding they may not be correct, clear, or applicable.

When Peter Hansteen presents his PF Tutorials, he starts with a slide titled, This is not a HOWTO which contains a pledge. He asks everyone in the audience to recite the text of the pledge out loud. It's fun to see, but its an important message.

So when it comes to networking, please try to stick with the OpenBSD FAQ chapter on Networking, if you can, and use it as your primary guide. This is still Chapter 6, though the current changes to implement CSS on the website have the chapters unnumbered on the index page. And within, you'll find a discussion of bridge use in FAQ 6.6, where an example shows a bridge between two types of Ethernets. I use bridges, yes, but to interconnect Ethernets when that is actually needed. And while bridging is used, it is not ubiquitous.

Generally, the only bridge use I have seen in 3rd-party "set up a router" how-tos are for computers with a string of NICs, and the authors usually do this to make to make the computers' string of NICs behave something like a router with an integrated switch, such as your ISP's router likely has. But that artificial "turn my computer with a string of NICs into a switch-like device" limits your ability to manage packet filtering or traffic shaping. Thiis is because configuring packet filtering with bridged Ethernets is more complex than with separate networks.
In your first post, you assigned a static address to both NICs (em0:192.168.0.2/24, em1:192.168.1.2/24) and a gateway (default route) to the ISP's router at 192.168.0.1. That's three files: /etc/hostname.em0, /etc/hostname.em1, and /etc/mygate. If these configurations are unchanged, and if they were working before, then logic states these provisions are still correct. Since I don't see any obvious flaw with your PF configuration (other than a block rule that will never apply to any packets, because the subsequent pass rule apples to all traffic), I would test your network.

Can you ping(8) the ISP's router from OpenBSD? There's no routing involved, this is a ping on a single Ethernet segment and single IP subnet.

Can you ping() the Linux platform? Again, there is no routing involved.

If these fail, look to your ifconfig output. Are both em0 and em1 shown as active? If they are, did you accidentally swap cables?

Look to your routing table. Routing confused you, based on your first post. So here's a simple way of looking at routing of IP traffic.
  1. If a packet is destined for an address on the subnet, no routing applies.
  2. If a packet is destined for an address somewhere else, the sending computer needs to know the address of the router on the subnet to send the packet to for routing elsewhere.
  3. A routing table entry has two parts: a) the range of addresses the router manages, and b) the address of the router on the local subnet.
A default route -- the most common occurrence -- routes all packets headed elsewhere.

And all routing tables only need to have the range of applicable addresses, and the address of the next router.

So your Linux box only needs to have a single router entry, a default route of 192.168.1.2 -- the address of the OpenBSD router on its subnet.

Your OpenBSD box will have multiple routes. Its default route, the address of the ISP's router at 192.168.0.1, and the MAC addresses of any devices its talked to on the 192.168.1/24 subnet, which it knows it can reach directly through em1 due to the IP address and netmask setting for that NIC.

If you are still at a loss, post the output of $ ifconfig -A, which will be the provisioning and state of all NICs, and $ route -n show -inet which will be the state of the routing table. If you need to post them, or any other console output or configuration file info, please wrap each in [code] and [/code] tags for readability. You may not have noticed, but ocicat has edited both of your posts to add these for clarity.
Lesson learned (I hope for long) sometimes trying to save time, when you're in a hurry, can have these effects.
Reply With Quote