Messages

What benefit does this provide over just creating an ASN alias for AWS?  https://ipinfo.io/AS16509

A1: OP is solutioning for pass/allow rule(s), which, as i'm sure you'd agree, should be as conservative as possible.

A2: not creating a pass/allow rule for every range under jeffrey's jurisdiction.

A3: sourcing a known-good list of ranges directly from its controlling parties vs. $unknown_place_opnsense_gets_and_maintains_its_asn_ranges

A4: accounting for the manner in which amz publishes those ranges. see 'Note' in block at top of https://docs.aws.amazon.com/vpc/latest/userguide/aws-ip-ranges.html

do you even firewall bro?  :P

Firewall, further to your suggestion, I outsourced the DNS resolutions to a pi-hole (running unbound), which I installed on a 12-year old Raspberry pi 1 :)

so...did it not work?

However, it is my understanding that the trick that solved the issue for me, was re configuring the WG connections from scratch (on second thought, I suspect that the issue was a conflict between the unbound running on OPNsense and the vpn provider's DNS).

...which led you to try this instead?

I can't believe I spent so much time looking for a solution in all the wrong places.. 

you didn't

Now I should test it with unbound running on OPNsense.

godspeed

@newsense, much like what i described as 'hacky workarounds' in responding to OP's specific request for a dnsmasq-based solution, this too is only as viable as the alias updates it relies upon.

@morik_opnsense, i'd suggest either allowing to all AWS ranges (see below) or further isolating the device. if your concern is based on possible phone-home to china do both.

establish initial list:

Code Select Expand

pkg install jq
curl https://ip-ranges.amazonaws.com/ip-ranges.json  | jq -r '.prefixes | keys[] as $k | "\(.[$k] | .ip_prefix)"' > /usr/local/www/aws_ranges.txt

establish update mechanism:
- firewall > aliases > add
- type 'url table (ips)', refresh frequency 5 days should be fine, content = http://127.0.0.1/aws_ranges.txt

then your pf rule just needs to block all vacuum traffic with exception of aws_ranges alias.

more fun with add'l points: after poking around at the hosts listed at https://www.virustotal.com/gui/domain/roborock.com/relations i'd hire a maid instead. :)

You don't recommend adguard plug-in on Opnsense?

i'd never use nor recommend it, and tbh i feel those that do are comfortable with disregarding opsec in favor of convenience.
https://www.reddit.com/r/Adguard/comments/t05r9v/russian_app_safe/
https://www.reddit.com/r/Adguard/comments/t05r9v/comment/iqtcxqg/

generally speaking, you'd spare hair follicles and/or restful sleep by moving resolution elsewhere on your lan. there are countless ways to skin that cat, clearly, but i've had near zero problems with pi-hole running a local instance of unbound.

this blog attempts to clarify how the different components of / config options for, dns resolution on opnsense, interoperate. have a look if you haven't already but fwiw i surmised that dns subsystems on opnsense are convoluted at best and bordering on broken either way.

that said, you can (probably) hack something together that'll function...
- have you defined a gateway for the vpn? i couldn't understand from your post of "without setting a static ip" was intended behavior or merely the outcome of whichever tutorial you followed.
- option 1: set a static route (system > routes > configuration) for the ip addresses corresponding to your dns forwarder (e.g. 9.9.9.9), specifying the vpn gateway.
-option 2: revise gateway priorities to, in essence, force opnsense to choose your vpn gateway(s) as default (e.g. VPN_GW priority 100, WAN_GW priority 255). i'd advise this regardless if you're mitigating most wan traffic being sent in the clear. be sure you've configured static routes for your vpn endpoints such that their traffic is sent via wan.

Hey, that's my quote...
Could you please quote the full context / post I did respond to? Condescending rhetoric is the last I was thinking of reading the original message:

OP pasted a link to opnsense docs, says it could be half as long and twice as useful, you essentially reply "ok where's your whiz-bang how-to if theirs sucks?"

this is, speaking from personal experience and numerous observations in the 4 years since, the typical forum response to anyone critical of opnsense documentation.

if its not what you intended, well, i apologize on behalf of those whom afforded that presumption.

If I'm understanding the ask, you want to route outbound traffic with a certain destination port number, across the VPN? Assuming it has it's own interface+gateway all you really need to do is create a rule on the appropriate interface; likely LAN, which I'll use in the example below. If not, be sure your Interface and Source settings are aligned.

Code Select Expand


Action: Pass
Quick: Checked
Interface: LAN
Direction: In
TCP/IP Version: IPv4
Protocol: Per your needs (likely TCP)
Source: LAN Network
Destination: Any
Destination Port Range: Per your needs
Gateway: Whatever the gateway is associated with the VPN (should be obvious when you trigger drop-down menu)

The last 2 lines are where the magic happens.

Where can we find your lean-and-mean, just enough, easy configuration How-To, really like to read it.

More than just awful documentation--it's that this is the de facto response to anyone willing to speak up about it.

It's FOSS; we get it. Unless we pony up the cost of support fees (should the option exist as it does here), one should make reasonable expectations for forum response times, access to experts, etc.

With that aside, in what world does it make sense to ask users with problems they can't solve to revise product documentation? Beyond the simple fact they're exceedingly unlikely to develop the software itself, surely those aren't the manner of technical experts you want authoring howto's for the masses? ::)

I'm appreciative of the project and the active forums but FFS the frequency of condescending rhetoric leaves a stain I can't be the first one to note.

You should be able to smooth this over a bit by disabling sticky connections (advanced firewall settings). Research the possible implications of doing so, however. I ventured down that path and encountered more bullcorn than benefit.

As for how to flip it back to WAN1 with sticky conn enabled, you might have success with automating ifdown/ifup on WAN2 if a test for connectivity on WAN1 succeeds (shellscript+cron). Also you may need to account for the gateway interval period by inserting a sleep routine in the script.

These are the commands I use for another LTE connectivity need:

Code Select Expand

/usr/local/sbin/configctl interface linkup stop ue0
/usr/local/sbin/configctl interface reconfigure ue0
/usr/local/sbin/configctl interface linkup start ue0

while i can't say i endorse hacky workarounds i understand you gotta do what you gotta do to make shit work.

i gather that you're using aliases+pf rules to lock down traffic to the furthest extent possible on what reads like an iot vlan. if the devices only have access to manually-whitelisted endpoints and your vacuum wants to reach a mystery machine hosted on AWS for which you can't make a threat assessment, why not just allow access to any & all AWS ranges? the list is published & updated¹ but you'll either need to parse the json (e.g. with jq ) or find a reliable source of these same data in a format consumable by opnsense...i'm sure such a thing exists. you might also use that step to remove any ranges not associated with EC2 (your hostname resolves to an elastic load balancer host and all IPs it distributes, in your case, are EC2).

stated otherwise, if it were to start connecting to another EC2 server(s) tomorrow (which it already has and will continue to do), you'd have no better insight into its purpose than you do already so you'd allow it. is it a broad swath of ip space? absolutely. are you going to mitigate newly introduced threats from that one device by restricting its traffic to a subset of ranges on the same service?  i'd say its a near zero chance but i'm sure some swingin' d**k cybersec expert with more certs to their name than they have common sense would disagree.

also imho you should call the alias for vacuum endpoints 'this_shit_sucks' for obvious reasons.

add'l point... pihole-FTL shares enough code base with dnsmasq to describe it as being functionally similar, and as such it will parse and leverage config files in /etc/dnsmasq.d/. from a workflow perspective these options are considered before its forwarding mechanism (to resolvers defined via pihole UI) kicks in. ootb, nothing that can meet your desire for pf rules unless you leveraged it to generate a locally-hosted reference for alias lookup via url on opnsense (e.g. alias = http://192.168.69.69/this_shit_sucks).

add'l point 2...if you insist upon addressing it with opnsense you should still be able to make it happen by:

• change dnsmasq listen port to something besides unbound's port 53, e.g. 53053
• add override for roborock.com at opnsense > domain overrides, specifying 127.0.0.1@53053 as authoritative nameserver
• figure out what cli voodoo is required to add/modify dnsmasq configs on opnsense (making sure they persist)
• cross fingers, pray to the networking gods regularly, and research alternatives in the interim

add'l point 3...subjectively, trying to do *more* with dns on opnsense vs. moving it elsewhere has led to more problems than solutions for me (e.g. host blocking via unbound DNSBL on opnsense will give you heartburn, not exploring the adguard community plugin is an exercise in sanity preservation, i could go on). i'm sure circumstances such as migrating to unbound as default, changing ddns clients, etc don't help matters much but i'm not in the business of making excuses for time wasted.

¹ https://ip-ranges.amazonaws.com/ip-ranges.json

Surely there is something built-in to opnsense that can get the internet back without rebooting from within the GUI?

unfortunately not.

Didn't think I would have to cron a script to reboot as mentioned a few posts above.

you might look into finagling a cron script to restart the interface instead of rebooting the entire machine. these are the lines i use for just such an approach:

Code Select Expand


/usr/local/sbin/configctl interface linkup stop ue0
/usr/local/sbin/configctl interface reconfigure ue0
/usr/local/sbin/configctl interface linkup start ue0

don't let the naysayers poopoo the use of cron for something alternatively addressed with the likes of redis. until a redis plugin for opnsense gets closer to feature parity with CLI the amount of sorcery involved in making it work simply ain't worth the trouble.

@mb has there been reconsideration of allowing users to disable communication with sunnyvalley servers? you seem to have focused on the riders in this thread vs. the arguably more significant group. on one hand you have existing forum users whose ignorance of privacy maintenance rush to defend something they've already installed. on the other, several users created a forum account to add their concern after searching the web for similar answers.

how did your opportunity cost analysis manage to suggest that you forego an unknown number of free users in favor of data collection?  how many of those same users could have been upsold & transitioned to your saas offering over the last 3 years? i imagine those KPI might also be valuable for to the investors you reference, yet you're operating blindly.

i've spent quite a bit of time with tools such as suricata, wazuh, maltrail, security onion / zeek / elk stack, zabbix / nagios in the interim, and i've found some combination thereof to meet (if not best) my understanding of zenarmor features & functionality. though i'd enjoy familiarizing myself with zenarmor i'm patient enough to wait for our ability to operate it in the absence of data collection. after all, you don't need it.

To be frank, clustering loosely related reports, answered and unanswered threads for 22.1 and 22.7 and solved issues with 22.7 I'm not sure what I should be looking at.

"loosely related" reports that all point to a common issue with wan connectivity; likely pertaining to intel nics. never acknowledged as a common issue and apparently one which users continued to experience for the duration of 22.1 series despite numerous purported workarounds.

i'm on 22.7.4 now and i still have the issue.

i don't know what to tell you that i haven't already besides "it's not working the way it's supposed to".

[Question]

The upgrade to 22.x earlier this year was accompanied by rather severe WAN connectivity issues experienced by many forum users and often echoed by others. These are unique posts from 22.x.

Though admittedly a few of the links above are only possibly related to the underlying issue I'm sure I didn't track down 100% of the threads that were.

Given the extent of my digging I trust it's evident that this has been a major thorn. Regardless, I've stuck with OPNsense with the hopes that a fix would arrive eventually.

Question: noting the handful of interface and dhcpd items in the changelog for 22.7, were any of them intended to address this issue? If not, did the 22.7 release unwind any related changes that may have been introduced with 22.1?

[not]

The common denominator in this thread seems to be MAC spoofing. Why is this necessary?

many, myself included, have experienced this issue since the 22.x upgrade despite not using MAC spoofing.

Not 100% sure I'm following your intended outcome but you probably want to use FW rules here...

• Ensure "new WAN" has it's own gateway configured
• Change the LAN gateway back to "auto-detect"
• Create a new LAN firewall rule = " pass from LAN Network to * "; likely below all blocking rules and/or other allow rules for traffic between local networks.
• Set the gateway for the above rule = "new WAN"