1. you won't use pi-hole anymore. adguard home is a package available for opnsense that does the same thing better, natively right on your opnsense router.
2. opnsense makes this easy by default, block all incoming, allow all outgoing. dont open ports till you understand what you are doing and why you are opening it. (do not open rdp.)
3. I hate ubiquiti shit now but their APs are ok. Aruba and Rukus are next on my list to try at home
So... if I'm reading this correctly: it's as easy as buying a network firewall appliance that comes pre-loaded with OPNSense, a pair of access points, and then not being a complete and total retard with my defaults?
A lot of the things that made me bash my head against the wall with Pi-Hole were caused by my ISP's router. If Pi-Hole will be rendered entirely redundant by OPNSense, that takes a lot of the guesswork out of it for me.
So... if I'm reading this correctly: it's as easy as buying a network firewall appliance that comes pre-loaded with OPNSense, a pair of access points, and then not being a complete and total retard with my defaults?
A lot of the things that made me bash my head against the wall with Pi-Hole were caused by my ISP's router. If Pi-Hole will be rendered entirely redundant by OPNSense, that takes a lot of the guesswork out of it for me.
Yep. Protectli is a fairly popular hard brand for open source routing platforms such as pfSense/OPNsense. Used Dell/HP/Lenovo mini or thin clients you can find on eBay for cheap, often they will have at least 2 network ports or you can do an add in card. My pf/OPNsense router is a custom mini itx build with a low powered quad core celeron, 6gb ram, 60gb ssd, dual port NIC in a tiny case. Uses about 6-10W of power and has been running this way for 4-5 years at least now. Handles 1gbps symmetrical fiber with filtering no issue. The Protectli is very similar hardware to what I just listed. Stay away from onboard Realtek NICs. ServeTheHome.com is a good resource for finding more inexpensive hardware to turn into a pf/opnsense router.
The defaults out of the box are extremely safe. Even if you go screwing around with the config and think you've broken something it's very easy to re-default everything even if you can't access the webgui. Backups can be restored very quickly before big changes, the UI is very helpful in not letting you screw things up.
You will likely also need a network switch to go inbetween the router and access points/other PCs/devices/etc. Getting one with PoE is a huge plus so you don't have to use power over ethernet injectors to power your APs.
If you aren't very familiar with networking I could see how pihole caused trouble with your ISPs router, sometimes they don't play nicely depending on how shitty your ISPs is. My first rule of thumb is to remove/disable as much of the ISPs hardware as possible and run my own. One other thing to mention is if you move forward with a setup like this you can always test/play with it before hand without exploding your entire home network right off the bat
Set up my mikrotik. It is extremely overwhelming at the beginning, there's a fuckton of tabs and options and acronyms and I barely know the basics lmao
But I got it working slowly over time. Set up the firewall first and then set up PPPoE. Figured I needed a VLAN and added it with the id my ISP provided me, though I am not sure I need another VLAN for my traffic. The VLAN is relegated to the ether1 port which is also a WAN port and the rest are LAN, so it shouldn't be needed is my guess.
I have no idea how NAT works yet, I left it as the default "masquerade" option and it works. No clue how to port forward either yet.
Technically I should have IPv6 but it seems like it doesn't get assigned to me. As I did not set up the firewall either for that, for now I drop everything that comes through IPv6 (should it somehow get assigned)
I noticed that port scanning is way more common than I thought. On my previous router I could only detect a couple attempts per hour, with this one I see about 10 a minute.
The ability to export configurations is baller.
add action=drop chain=input comment="drop invalid" connection-state=invalid \
log=yes log-prefix=INVALID
add action=accept chain=input comment="Allow LAN IPs" src-address-list=\
allowed_to_router
add action=accept chain=input comment="accept established,related" \
connection-state=established,related
add action=accept chain=input comment=Management dst-port=22,80,8291 \
in-interface-list=LAN protocol=tcp
add action=drop chain=input comment="drop all not coming from LAN" \
in-interface-list=!LAN log=yes log-prefix=NOTLAN
add action=drop chain=input comment="Drop everything else" log=yes log-prefix=\
DROPPED
add action=drop chain=forward comment="Drop Invalid" connection-state=invalid \
log=yes log-prefix=INVALID
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \
connection-state=established,related hw-offload=yes
add action=accept chain=forward comment="accept established,related" \
connection-state=established,related
add action=drop chain=forward comment=\
"Drop connections to public addresses from LAN" dst-address-list=\
not_in_internet in-interface-list=LAN log=yes log-prefix=NOTINTERNET
add action=drop chain=forward comment="Drop incoming from outside lan range" \
in-interface-list=LAN log=yes log-prefix=OUTOFRANGE src-address=\
!192.168.88.0/24
add action=accept chain=forward comment="Accept LAN" in-interface-list=LAN
add action=accept chain=forward comment="Allow LAN to WAN" in-interface-list=\
LAN out-interface-list=WAN
add action=drop chain=forward comment=\
"defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat \
connection-state=new in-interface-list=WAN log=yes log-prefix=NOTDSTNAT
add action=drop chain=forward comment=\
"Drop incoming from Internet with source private IP" in-interface-list=WAN \
log=yes log-prefix=FROMWANWITHLOCALIP src-address-list=not_in_internet
add action=drop chain=forward comment="Drop everything else" log=yes \
log-prefix=DROPPED
Some of these rules are probably pointless or redundant.
ShieldsUP website tells me two ports are closed instead of stealthed (135 and 445), though I did verify that this happened with my other router too, and adding explicit rules to outright drop packets for those ports does nothing, so I think it's something on the ISP end?
i owe you one piwo tesco @Slav Power
You could do a full export and I could take a look and let you know what to change. Keep in mind that even if you don't do show-sensitive you might want to additionally redact some info like MAC addresses, and with file="" you can save it to file to download it or even upload via FTP or other protocol for backup.
So: add action=accept chain=input comment="Allow LAN IPs" src-address-list=allowed_to_router
Get rid of this one, and modify add action=accept chain=input comment=Management dst-port=22,80,8291 in-interface-list=LAN protocol=tcp to include src-address-list=allowed_to_router, and make sure that allowed_to_router only includes your local subnets, so assuming that you're using Mikrotik's default, that would be ip/firewall/address-list/add 192.168.88.0/24 list=allowed_to_router. Delete the defconf rule for
"drop all not coming from LAN" since it's unnecessary.
Remember: the input chain is for traffic that goes to the router device, so if your router is facing the Internet directly, you want to keep it air tight. Less is more, and the simplest tight config would look like this:
Now, remember that if there are no rules on a chain, all packets go through, and if there are, the packets go from top to bottom. Fourth rule will block any packet that goes through the chain, that's how you set up explicit filtering, but if you were to only have that rule you'd lock yourself out of the router. That's why the two accept rules are important.
First, "Accept established,related" will ensure that if there is a connection open to the router, for example a WinBox connection between your PC and the router, the packets will go through, but the "Router management" rule is probably the most important one. This is my rule and it's extremely tight, so you need to pay attention that it's all in check. It assumes that your service ports at ip/service are 22 for SSH, 80 for HTTP and 8291 for WinBox, AKA the defults. It also assumes that the physical LAN interfaces you use to connect with the router are added to the LAN interface list, and finally, that the local IP address of the device that you want to connect with is defined in the correct address list. Only if all of the criteria is met will the packet go through, and if you omit any of the parameters, you're locked out. Putting "Drop invalid" at the beginning is just a nice precaution since there is no sense in processing packets that are fucked, but then without these two rules you'll be locking yourself out of the router.
Now, in my experience, with this input chain configuration, your router is practically invisible to the Internet, as the only way a connection can be established if it's explicitly coming from your local network to the management ports, and otherwise all packets get dropped. I used to get outside SSH login failure log messages, but now I don't, because no outside connections to the router can be made to begin with. I had to define an ICMP accept for LAN interfaces rule to be able to ping the router from LAN for example. That's why this is a safe configuration, but you have to understand how it works to not fuck yourself over, be it by dropping stuff you don't want to drop or accepting stuff that you don't want to accept.
Fun fact: I just locked myself out trying to see if using WinBox's Safe Mode would properly unroll me disabling these two rules after I inevitably disconnect. It didn't and I got locked out, but thanks to me setting up the management port that uses the WinBox MAC Server I could quickly replug into it, connect back via WinBox and enable them again. It's a really good idea to have more ways to access your router's configuration than just TCP/IP if you don't want to reset/Netinstall that bitch. You should consider doing this yourself, or if you feel brazen you can just let the entire thing be active on all LAN interfaces at any time.
Oh, and make sure to make backups. Both by export show-sensitive and by /system/backup. Be sure to have the pure text backups, I've made the mistake of relying on just the .backup files until they wouldn't properly restore.
As for the forward chain:
Works the same as the input chain. Also remember what FastTrack does since that can help you wasting hours on trying to diagnose why your filter rule, queue or some other setting won't work. And remember that the Mikrotik documentation is your friend.
private fiber runs in datacenters are ridiculously expensive, and if one more fuck tells me on the phone they need "qualified professionals" to do it, a fucking trained ape could do it. If i can step on a plane to get over there and make those 2 bare metals kiss for a fraction of the cost theres something wrong with you.
My local datacentre charges something fucking ridiculous for what they call "Direct Connect". I asked for a tour a few years ago and got them to show me what was involved in that. They literally were like "yeah we just plug your ethernet cable directly into this switch at the top of the rack, then get another ethernet cable and plug it directly into your other server located in the centre here" like ffs man it was like an additional $250/month for servers to have Direct Connect. They won't allow you to have 2 servers directly next to each other unless you buy the whole shelf (offered in 10U, 24U and 48U racks) which is ridiculously pricey at all stages.
That one I added specifically because without it I have no access to the Internet, literally nothing loads and I can't figure out exactly why it's necessary.
I applied all other suggestions, will redact and post full config later in the day
also doing a little experiment with niggerlisting IPs that hit specific ports, mostly out of curiosity
That one I added specifically because without it I have no access to the Internet, literally nothing loads and I can't figure out exactly why it's necessary.
I guess that it's because by default, MikroTik is the default DNS server, and for it to work you'd need to define DNS port access. However this is a retarded decision on MikroTik's part, as by having /ip/dns/set allow-remote-requests=yes as defconf, if you have any sort of leak in your firewall config, your DNS is now open to the world, and a lot of bad things can happen. So for starters:
Code:
/ip dns
set allow-remote-requests=no
set servers=1.1.1.1,1.0.0.1
This will disable the MikroTik DNS server and directly pass all the DNS traffic to Cloudflare's DNS. Alternatively:
This will add the necessary rules to allow LAN devices to communicate with the router's DNS server but not letting anything else poke at it. Once again, this is the more complicated but safer way of doing things. You have to explicitly define what can go into the router, so if something doesn't work, you can have a strict definition of what has to be allowed for it to work.
As for port forwarding, this is the neat part about RouterOS. It doesn't have port forwarding. It's an abstraction, a coloqiaulism. You define NAT rules. Here's an example: add action=dst-nat chain=dstnat dst-address=x.x.x.x dst-port=2137 in-interface-list=WAN protocol=tcp to-addresses=192.168.88.14 to-ports=2137
Now, to dissect it. action=dst-nat - This is the action of routing the packet to a defined destination, in this case the LAN device that has the service that we want to open. chain=dstnat - We want to open up traffic that comes from outside the natted network so we define the rule on the dstnat chain. dst-address=x.x.x.x - This is completely optional, but it adds an extra level of tightness to the rule, albeit somewhat redundant. By defining your public IP as dst-address or dst-address-list you make sure that it only applies to traffic that's coming from WAN. Alternatively it can be used when you're running two different WAN connections and you want the rule to respond to the public IP of a specific uplink connection. dst-address-list can be used for dynamic IP's, and the ways that you can update it can vary from a DNS domain name, or a script that'll automatically update your DynDNS address of choice, but that's a topic for another time. You can do a ton with RouterOS scripting. dst-port=2137 - This is where we define which port is being queried by the device from WAN. in-interface-list=WAN - Self-explanatory, we want this rule to only apply to traffic originating from WAN. This makes the IP address rule redundant as the only source IP address from the WAN interface list will be our public IP address, but like I said, it can still be used if you have two uplink connections. protocol=tcp - We have to define if it's TCP or UDP. For example, BitTorrent uses both so we'll want to define this rule twice for both protocols. to-addresses=192.168.88.14 - The local IP address of the LAN device that we want for our Internet clients to connect to. to-ports=2137 - This will be the port defined in whichever software that we have running on the aforementioned device. This is the case in all routers, but the reason you have two port definitions is because you can tell people to connect to port 5080, but your server is listening to port 8090. Nothing's stopping us from translating these ports during natting.
If you want to define a port range, you just gotta do something like 5000-6000.
NAT rules in RouterOS can also be used to translate addresses within your LAN, so for example, if your local service is on an address 192.168.100.5:200, we can define a NAT rule that will direct traffic to this address and port if we decide to communicate with 192.168.200.50:100. There's also hairpin NAT for creating a loopback so that when we try to access a service on our LAN from a WAN address, for example a DynDNS domain, it will reroute the traffic back to LAN so that we won't have to enter the LAN IP every time we want to visit that service locally. But again, topic for another time, always remember that MikroTik Docs are your friend.
I guess that it's because by default, MikroTik is the default DNS server, and for it to work you'd need to define DNS port access. However this is a retarded decision on MikroTik's part, as by having /ip/dns/set allow-remote-requests=yes as defconf, if you have any sort of leak in your firewall config, your DNS is now open to the world, and a lot of bad things can happen. So for starters:
Yep, I figured it out after disabling the rule allowing all LAN traffic and looking at the logs, it was DNS and DHCP
I explicitly allowed DNS and DHCP on LAN ports, could also use another DNS like cloudflare's or google's but I have nothing against my ISP DNS at the moment so it can stay.
Not sure if the forward chain rules "DROP connections to invalid addresses from LAN" and "DROP incoming from outside LAN range" are necessary, but I see them drop packets from time to time, usually when online play is involved. No noticeable disruption of service.
the niggerlist is for my own amusement mostly. I'll run it for a week or two and see if I can get a couple ranges to outright block.
ty for the guidance on how to "port forward"
Not sure if the forward chain rules "DROP connections to invalid addresses from LAN" and "DROP incoming from outside LAN range" are necessary, but I see them drop packets from time to time, usually when online play is involved. No noticeable disruption of service.
The counter goes up because those packets get caught by these rules before they get to the "Drop everything else" rule, but you're free to remove them as then "Drop everything else" will devour everything you haven't explicitly allowed anyways.
Code:
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1 list=WAN
add interface=pppoe-out1 list=WAN
Feel free to drop the ether1 rule, since your actual Internet traffic goes through the PPPoE interface. You can verify it with the Torch tool, eth1 will only have a handful of encapsulated connections to the ISP, while the PPPoE interface will have every current Internet connection active. The Internet VLAN will only encapsulate the PPPoE session. So for proper network filtering you only need to define pppoe-out1 as the WAN interface, since that's the only one that's directly facing the Internet and the rest is ISP encapsulation.
Just define this as 192.168.88.0/24. /ip firewall service-port
If you ever want to do SIP calling, disable the SIP service port here. That's MikroTik's SIP "helper", and these "helpers" are known to fuck up SIP connections on every router of every manufacturer that has this "feature" and has it enabled by default.
Code:
/system routerboard wps-button
set enabled=yes on-event=wps-accept
Chateau?
Code:
/tool mac-server mac-winbox
set allowed-interface-list=none
Like I said, consider setting up a management port for it. The way I've set mine up is I've unhooked one of the Ethernet ports from everything else, assigned to the MGMT interface list and defined it as the MAC Server interface list of choice. Then if I hook into that port directly it won't assign me an IP address, it won't connect me to the Internet, but it will allow me to configure my router via the MAC address from WinBox. A life saver, just like when I locked myself out a few posts ago.
Other than that, and all the Firewall configuration I've mentioned, it looks alright. As for the DNS, you can unhook "Allow remote requests" and then the firewall rules won't be necessary as MikroTik should just assign the defined DNS addresses to the clients that would then connect to those directly, but the neat part about the router being a standalone DNS server is that you can define your own DNS records for things like local addresses, or even add hosts blocklists, because yes that's now a thing in RouterOS, you have a built-in domain blocker for network wide adblocking. I still prefer using Pi-Hole cuz it's more robust, supports ABP lists and other things like that.
@Slav Power, any chance of having a look at my MikroTik firewall config and letting me know if there's anything retarded in there? I'm coming from the Unifi ecosystem where there's much less scope for me to fuck myself over.
I've got almost everything I want to get set up working but besides a sanity check on the firewall, the one thing that I'm getting nowhere with is trying to have any domain/ip on the Firewall>Address Lists be routed through my VPN. I already have it working with a selected VLAN but I'm wanting those specified domains (KF amongst them) to be routed regardless of the VLAN in use. The reason I want to do it that way is that I think it should be possible to have that Address List auto update with a scheduled script which clears the entries on the Address List with a specified list name and then runs a bunch of commands like "/ip firewall address-list add list=[listname] address=kiwifarms.net " on a fixed interval. That way if an IP changes I don't have to fuck about manually updating it all, and if I want to add more sites to the list I just add them to the end of the script. I did get the routing working briefly but for some reason the connection to those sites were horribly slow.
I can, but to clarify, I'm not an expert and sometimes I struggle with it myself. Though your idea of routing certain domains via VPN sounds interesting and I may try doing something like that myself.I have a spare hAP ac2 that I could test this shit on too.
Its still appreciated. As I said, coming from Unifi and having never used MikroTik hardware the MikroTik way of doing things is pretty intimidating. It's all pretty much the default configuration but there is stuff I've added over the last couple of days I've spent getting things set up which could be wrong/redundant.
Code:
/ip firewall filter
add action=accept chain=input comment=\
"defconf: accept established,related,untracked" connection-state=\
established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment=\
"defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=drop chain=input comment="defconf: drop all not coming from LAN" \
in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" \
ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" \
ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \
connection-state=established,related hw-offload=yes
add action=accept chain=forward comment=\
"defconf: accept established,related, untracked" connection-state=\
established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" \
connection-state=invalid
add action=drop chain=forward comment=\
"defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat \
connection-state=new in-interface-list=WAN
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" \
ipsec-policy=out,none out-interface-list=WAN
add action=masquerade chain=srcnat out-interface=xxx
/ip route
add disabled=yes distance=1 dst-address=0.0.0.0/0 gateway="" routing-table=\
main scope=30 suppress-hw-offload=no target-scope=10
add dst-address=0.0.0.0/0 gateway=xxx routing-table=xxx
/routing rule
add action=lookup disabled=yes dst-address=0.0.0.0/24 interface=*15 \
src-address=x.x.x.x/24 table=main
add action=lookup disabled=no src-address=x.x.x.x/24 table=xxx
Though your idea of routing certain domains via VPN sounds interesting and I may try doing something like that myself.I have a spare hAP ac2 that I could test this shit on too.
This is one of those things that I really want to make work. Not just for what I'm looking at when I'm home but also if I'm out of the house I'll be able to have my phone/laptop etc VPN'd back in and have the same routing take place no matter where I'm at.
It's all pretty much the default configuration but there is stuff I've added over the last couple of days I've spent getting things set up which could be wrong/redundant.
Not sure what's up with that extra masquerade rule. Is it defined for the VPN interface? In terms of opening yourself up it all seems to be stock so there's no issue there, as long as you trust the defaults. I prefer the explicit way of doing the firewall like I described.
Not sure what's up with that extra masquerade rule. Is it defined for the VPN interface? In terms of opening yourself up it all seems to be stock so there's no issue there, as long as you trust the defaults. I prefer the explicit way of doing the firewall like I described.
Some Wireguard questions
I was thinking on how to further harden Wireguard access to the router to VPN into my home network, as I understand you need to have the public key of the router and the router has to have yours, which seems safe enough but I am noided so I came up with some ideas:
Whitelisting IP address: I have no way of knowing my IP address before moving, plus it might be dynamic
Whitelisting MAC address: Could work, can spoof a MAC easily and can be set up beforehand
Port knocking: Could also work in conjunction with above, knocking on a port adds you to a list for 5s and if you try to connect to the wireguard interface in that time frame and you are on the list it will let you connect
Additional fail2ban rule: knock on the port enough times in a time frame adds you to a 1w blocklist (maybe unnecessary)
something else?
I have no idea on how to set up redundancy still. I could have a second Wireguard interface with another keypair isolated to it's own VLAN with only Winbox access I guess. Seems flimsy.
As for the DNS, you can unhook "Allow remote requests" and then the firewall rules won't be necessary as MikroTik should just assign the defined DNS addresses to the clients that would then connect to those directly
This doesn't work as the DNS does not propagate to the clients for whatever reason, it would have to be set manually on the device. I'll keep remote requests on for now as I might have a use for resolving local addresses.
Some Wireguard questions
I was thinking on how to further harden Wireguard access to the router to VPN into my home network, as I understand you need to have the public key of the router and the router has to have yours, which seems safe enough but I am noided so I came up with some ideas:
Whitelisting IP address: I have no way of knowing my IP address before moving, plus it might be dynamic
Whitelisting MAC address: Could work, can spoof a MAC easily and can be set up beforehand
Port knocking: Could also work in conjunction with above, knocking on a port adds you to a list for 5s and if you try to connect to the wireguard interface in that time frame and you are on the list it will let you connect
Additional fail2ban rule: knock on the port enough times in a time frame adds you to a 1w blocklist (maybe unnecessary)
something else?
I have no idea on how to set up redundancy still. I could have a second Wireguard interface with another keypair isolated to it's own VLAN with only Winbox access I guess. Seems flimsy.
This doesn't work as the DNS does not propagate to the clients for whatever reason, it would have to be set manually on the device. I'll keep remote requests on for now as I might have a use for resolving local addresses.
Generally speaking, Wireguard is safe by default. It's UDP only, meaning that it's impossible to find it's port by brute force, there is no TCP handshake that's the basis of finding out an open port. Furthermore, the only way an open Wireguard port responds is if you send a packet with valid keys, and those are set up per client, and if anything is off the packet gets dropped, so the requester sees it as if there was nothing there. So you shouldn't really worry about it, only worry about it if someone gets their hands on your Wireguard configuration with your keys, because that's the only realistic way you can brute force yourself into someone else's WG tunnel.
For redundancy I guess you could utilize Mikrotik's Back To Home which will route you via their proxies in case a direct connection cannot be established.
The DNS problem is interesting, as AFAIK all that I have in my configuration is the IP address of Pi-Hole in IP>DNS and when that's down it gets changed to Cloudflare's DNS and the clients get it correctly with "Allow remote requests" being off.
Like I said, consider setting up a management port for it. The way I've set mine up is I've unhooked one of the Ethernet ports from everything else, assigned to the MGMT interface list and defined it as the MAC Server interface list of choice. Then if I hook into that port directly it won't assign me an IP address, it won't connect me to the Internet, but it will allow me to configure my router via the MAC address from WinBox. A life saver, just like when I locked myself out a few posts ago.
Not sure what I am doing wrong with this.
I uncoupled ether5 from the bridge, gave it its own interface list "emergency access", gave that list to the MAC server thingy, I grab the MAC from the ether5 port, plug ethernet cable to ether5 and it doesn't connect. Syn timeout.
I allowed complete access to the router from that interface list to exclude firewall issues. I fucked around with RoMON and it still doesn't work. Any advice?
It's a weird issue with WinBox when you have more than one network interface or something like that. For example, I've set up a management VLAN which WinBox sees but Syn timeouts on, and on my laptop I have to disable WLAN amd WWAN for it to connect over Ethernet to eth5.
