Firewall Lists to URL + subdomains

RouterOS General
1

Hi all,

I’ve been asked to allow port 443 from a particular URL as well as associated subdomains.

E.g.

Port 443 from abc.com as well as *.abc.com

I’ve set up the Address List and associated Firewall Rules, however it does not appear that traffic is passing through this rule.

/ip firewall address-list
add address=abc.com list=abc.com
add action=accept chain=input dst-port=443 in-interface=nuroWAN port="" protocol=tcp src-address-list=abc.com

Also, will this configuration apply to any subdomains with abc.com, e.g. yyz.abc.com ?

For testing purposes, I would like this rule to apply only to one host on our network, how could I have this rule apply to one IP rather than the entire network?

Could you please help?

2

Your rule matches one destination IP address, not “a URL.” This is an important distinction because it won’t work in the face of dynamic DNS updates (short of a firewall reload) or more importantly in the face of services that use multiple servers so that one DNS name maps to potentially many IP addresses. Both problems may combine, as in the big cloud services, where doing a DNS lookup may give a different list of results from one minute to the next as the cloud continually reconfigures itself.

Combine that with your wish for “port 443,” which I feel safe in assuming means HTTPS, thus encryption, which means we can’t look inside the stream to find out where the user is trying to go. Search this forum for the many threads on blocking services like YouTube, Facebook, etc. This is not a trivial problem.


as well as associated subdomains.

If it’s a simple service with one IP per DNS subdomain name, you can list them one by one in your address list.

If the service uses a single IP address block, it would be more efficient to skip address lists and give the IP block in CIDR notation.

Either way, your rule isn’t doing a textual match on the URL. RouterOS firewall rules work on IP addresses at bottom, not on URLs, and even if they did, there’s no way to see the full URL in the face of encryption.


chain=input

>

All the above aside, you mean "forward" here, not "input". The input chain is for traffic destined for the router itself. (e.g. WinBox connections.) Traffic transiting the router is forwarded traffic.
\
\
<br>
> ```text
in-interface=nuroWAN

This is another likely error: as I read your problem, you’re trying to filter traffic going out the WAN interface, not in from it.


how could I have this rule apply to one IP rather than the entire network?

“src-address=192.168.88.99”

3

Thanks for the reply.

This is another likely error: as I read your problem, you’re trying to filter traffic going out the WAN interface, not in from it.

No, we want to allow incoming traffic to the WAN interface on port 443 from domain abc.com (as well as subdomains *.abc.com)


All the above aside, you mean “forward” here, not “input”. The input chain is for traffic destined for the router itself. (e.g. WinBox connections.) Traffic transiting the router is forwarded traffic.

That makes sense, thank you! Although the result is the same unfortunately, and I don’t see any traffic through this rule.

“src-address=192.168.88.99”

since we are using a source address list of an external website, shouldn’t in this case be dst-address meaning one PC on our LAN?

4

You’ve got it backwards. From the RouterOS firewall’s perspective, the request is coming from src-address=WHATEVER, going out the WAN interface, and making a request of this abc.com service. The firewall acts on things from its own perspective, not from the perspective of the internal host or the remote service.

Having corrected this, I expect your rule still won’t work because of the DNS and encryption issues I brought up above, plus details like connection tracking that we haven’t even covered yet.

Seriously, do yourself a favor and review those other threads, searching for “YouTube” and so forth. I realize you’re trying for an “allow” rule and not a blocking rule, but the matching problem is the same either way. This horse has been beaten to death already.

5

What type of service are you running?

A vpn simply works, not sure what you are trying to accomplish??

6

Hi Avnav,

Thanks for the reply. It’s for troubleshooting a remote desktop application (Splashtop) whose client is often timing out, due to the connection dropping and they seem to think our firewall may be blocking them, or slowing down the connection somehow.

We are not blocking outgoing connections, they are suggesting we open incoming port 443 for their two domains. I’m not comfortable opening it wide open to our entire network, so would like to have it open for one workstation to validate whether they are correct or not.

Does this make sense?

7

Just to be clear, someone is attempting to gain access to a desktop behind your MT router ( what I think you are saying —> to a PC running same app or separate splashtop server??)
OR
there is a user requiring to use the remote desktop software behind your MT router to gain access to a desktop out in the WWW.

(presumably this app works on port 443)
Note: —> https://support-splashtoponprem.splashtop.com/hc/en-us/articles/360035881433


I agree opening up your firewall to a large swath of users is plain nuts.
Why cannot they pinpoint a static/fixed IP address as the source?
Further DYNDNS names/urls are free from many providers, the MT router will resolve those and make it easy to apply a firewall address list to the Splashtop server or pc on your LAN.

In terms of exposing a single device behind your MT for test purposes, that can be easily accomplished.
Suggest a separate vlan with only access to internet and the dst-nat rule would point to this device…
However expect a lot of noise knocking on the door as 443 is a common port and in this case its not going to the router itself, but to your LAN…

Highly recommend change default port as per the link to something out off the way like 13245