• 13 Posts
  • 53 Comments
Joined 1 year ago
cake
Cake day: June 13th, 2023

help-circle

  • surfrock66@lemmy.worldOPtoaww@lemmy.worldI held a baby squirrel today!
    link
    fedilink
    English
    arrow-up
    14
    arrow-down
    1
    ·
    2 months ago

    I don’t want to speculate as to the fate of the baby, the corrugated sheet metal had to be moved and it was only a few minutes after I had removed it that we heard the squeaking. Nature is gonna nature, either the squirrel will survive, or a predator will get an easy meal. The thing is, within the family, we will probably ask “is that the squirrel all grown up?” every time we see a squirrel up there for the next few years. I think that’s the best outcome we can hope for.








  • Ok, good news, I re-imaged and after about an hour of tinkering it’s working. (My wife is a doctor who does tele-medicine from home so it was tricky to get a downtime, even riskier if I couldn’t get back to working; usually she works when kids are in bed and that usually my window for these kind of projects). I still have my old config backup; I have a lot of firewall rules and services to put back in (I had redirects for google trying to reach their dns from chromecasts to my pihole, I had a zabbix client pointing to my zabbix server, I had wireguard working and want to see if I can restore existing key exchanges, it was tied to my LDAP server, etc). I really want to compare my old backup with a new one when this is done and see if I can’t figure out what was broken. I want to document that because I found a bunch of people with similar questions that only had incomplete answers:

    1. From the CLI, the WAN interface was DHCP, I set up the lagg between my 2 ports (lagg0), created a vlan 99 interface off of it (lagg0_vlan99) and made that the LAN interface with a static IP and no gateway.
    2. I made a gateway for my 10.99.1.254 LAN gateway, had to assign it to the LAN interface when I made it. It is not tagged as upstream. One thing I noticed, WAN_GW is priority 255; it was 254 before. Just a difference I noticed.
    3. I made an alias for each of my VLANS that might need internet access
    4. In Outbound NAT, I switched it to Hybrid and made rules to allow traffic through to each VLAN.
    5. Under Firewall->Rules->LAN I created a pass rule for each VLAN (This will get tuned later)

    With this, LAN clients access the WAN, after putting in a port forward WAN clients can access things on the LAN, the firewall can ping both LAN and WAN.




  • I probably need to burn it down and restart, but I need to find a time the family will tolerate an extended outage. I did share some things on the opnsense forum though which might be useful here.

    1. My diagram. At the bottom you will see why I have /16; in truth, it’s from back when I only had a single subnet, and I made it /16 so I could use the third octet to form DHCP scopes. That’s how the network worked in my head and I knew the IP scheme, so when it came time to add VLANS much later, I just made those the 2nd octet, and that’s how we are here today. Maybe one day I’ll re-do that, but it’s not in scope right now: https://nextcloud.surfrock66.com/s/txnZdzxHaiA5t65
    2. I did an experiment with static routes last night. I have the static route in, so I untagged the “LAN_GW” as an upstream gateway, and tagged “WAN_GW” as an upstream gateway. No change in the ability for opnsense to ping anything (it can ping WAN, not LAN), however all my LAN clients lost internet. In this state, from opnsense, I ran a “ping -S 10.99.1.40 10.2.2.213” (that’s my DNS server). This failed, but interestingly enough I was looking at the live logs, and even though the interface is LAN, the source IP was the WAN IP. I’m very confused; I’ve confirmed the LAN and WAN interfaces are correct and they have correctly assigned default gateways. See the attached picture. This would make sense; is opnsense doing something to switch the LAN and WAN somehow? I’m blown away how this is the case; that being said, it makes sense that tagging the LAN interface as upstream allows traffic out.

    It feels like somehow opnsense is treating LAN like WAN or something? I don’t know the obfuscation feels like it’s hiding things. A “ping -S 10.99.1.40 10.2.2.213” shouldn’t show in the logs with a source of the WAN address, right???


  • Ok, it’s definitely an issue with the firewall not sending traffic from itself to LAN. It’s weird, it’s passing traffic, but it cannot ping or access anything on the LAN including things on the 99 VLAN (so it’s local VLAN). The DNS requests are for sure failing from the firewall…but they work fine for the rest of the LAN. Any client can get a DNS response from the DNS server on the 2 VLAN, and can access the resulting site.

    For now, I’m just excluding the wireguard thing, I think it’s a distraction to the problem that the firewall has some sort of bad routing going on.

    I have a diagram, but at this point it’s pretty local to the firewall itself and I think it’s around the gateway/route configuration. I got some advice on the opnsense forum that my static routes are wrong; they say to make a single static route of 10.0.0.0/8 instead of one for each VLAN, turn off “upstream gateway” on the LAN GW (which when I do that I lose all WAN connectivity…which is a concern but I can revert). When I do the cli configuration, and I assign an IP for LAN, it asks if I want to put a gateway; it kind of says “it should be yes for wan, but no for LAN” but if I do no, I can’t access the internet from any clients, and if I do yes, it ticks “upstream gateway” on the lan gateway. Something is awry, but I’m gonna try again after making some static route changes.


  • Ok, lot to go over. The /16 thing is just history; before I started this, I actually had a full /16 for my whole house as I thought I’d have hundreds of IoT devices one day, and used that third octet as a logical separator. I’ve kind of got that stuck in my head, so when I moved to a 10. system, I made the vlans/subnets the 2nd octet because I have so much IP memory of that third and fourth octet. It’s unnecessary, but tbh I know most of my IP’s by heart, and I went into this trying to drive complexity up a bit to further my learning. I don’t think necessarily changing them to /24 would solve the problem, because the complexity wouldn’t really collapse much. It’s things like the 3 network is for our minecraft servers/services, and 10.3.2.* represents the main one, 10.3.3.* represents the one my son runs, etc. It’s just muscle memory at this point. The L3 stuff is mostly good I think, I’m mostly concerned about the firewall.

    I know that opnsense can be the L3 device, but 1) part of my learning in this was to use kind of raw cli switch commands and not some web UI, and 2) I had the original L3 device before adding the opnsense box (I used to have a comcast modem as the upstream from the L3, now the L3 has a 0.0.0.0/0 route to opnsense, and that should upstream to the comcast device). I have a full VM dedicated as my DHCP/DNS device running bind9 and isc-dhcp-server which has been maintained for over 10 years; I’m not looking to offload that to another device and it works flawlessly on the lan (with an IP helper on each vlan).

    I am definitely confused how it does gateways. My understanding is, in opnsense, gateways are the part of the route definition, so you define the opnsense gateways to point to the gateways on the L3 device, they’re not on the opnsense box itself. When you add an interface, you select the default gateway for that interface from a dropdown, consisting of the gateways you defined elsewhere. Where I get goofed up and lock myself out is when I change the “upstream” checkbox or mess with the priority. I don’t know how it selects one or the other as “active” either. I’ve iterated on that a lot; the further I get, the more it feels like the obfuscation of opnsense is adding to my complexity rather than reducing it.

    It seems the only thing having routing problems are packets essentially originating from an interface on the opnsense; things on the LAN reach the WAN, things on the WAN reach the LAN, but wireguard clients terminating at the opnsense box can’t hit the WAN, and the opnsense box can’t hit the LAN (despite passing traffic).









  • This whole thing sucks because this kind of tech has the potential to be revolutionary. For people with paralysis, or those experiencing vision loss due to eye issues, the tech to interface nerves with sensors and inputs will be absolutely revolutionary. On the other hand, Musk has a terrible track record with safety and regulation, develops tech by abusing researchers and workers with unrealistic timelines and expectations, overpromises and under delivers, and responds with hostility to even the most measured criticism. Having his name tied to the version of this tech leading the news cycle will paint it in a dystopian light, raising the regulatory bar to “panic” levels with no nuance, and will likely result in pushing more realistic approaches to the tech back a significant amount of time, hurting those it would help most.