I'm trying to get around a 3rd-party firewall that blocks non HTTP traffic. I have a mAP installed on the customer's network and I typically have such devices connect to my server via Wireguard - but the traffic is blocked by their firewall. And I'm having difficulties working with the corporate firewall administration. I'm hoping they'll approve opening the ports I need but even if they do it's made me think about how I can safeguard for the future.

So...since outbound traffic on port 443 is allowed I'm thinking of trying to use that. However, my server already provides HTTP/S services so port 443 is being used. So I can theoretically identify the customer's IP with a filter - but I'd rather not have a site-specific rule for a remote if I can avoid it. Instead...I'm thinking maybe port knocking might be a solution.

The corporate firewall also blocks ICMP - so I can't use ping. I know how to setup port knock "listening" on my router - what I don't know is how to perform the "knocks" using Mikrotik scripts especially without ping. I know ports 80 and 443 are available for outbound, possibly also 53 and 25, but I don't know how to do that apart from telnet and I don't think I can script telnet to abort immediately.

Any thoughts?

I'm trying to get around a 3rd-party firewall that blocks non HTTP traffic. I have a mAP installed on the customer's network and I typically have such devices connect to my server via Wireguard - but the traffic is blocked by their firewall. And I'm having difficulties working with the corporate firewall administration. I'm hoping they'll approve opening the ports I need but even if they do it's made me think about how I can safeguard for the future.

I would assume that they will not co-operate with you on opening ports. My employer a few years ago also was blocking anything outbound that was not "commonly used". They stopped that after a year or so, so I assume they got tired of complaints about blocking legit traffic. They have a STRONG history of not believing that any employees do anything non-standard for their job.

So...since outbound traffic on port 443 is allowed I'm thinking of trying to use that. However, my server already provides HTTP/S services so port 443 is being used. So I can theoretically identify the customer's IP with a filter - but I'd rather not have a site-specific rule for a remote if I can avoid it. Instead...I'm thinking maybe port knocking might be a solution.

You may want to do some tests to see what ports actually do work. That will give you a better idea what you can work with.

The corporate firewall also blocks ICMP - so I can't use ping. I know how to setup port knock "listening" on my router - what I don't know is how to perform the "knocks" using Mikrotik scripts especially without ping. I know ports 80 and 443 are available for outbound, possibly also 53 and 25, but I don't know how to do that apart from telnet and I don't think I can script telnet to abort immediately.

Jerks...
I'm not sure I understand why you are trying to send the port knock sequence from your router - or do you have a second router at work that you are trying to use to set up the VPN?
I use port knocks for a variety of reasons inbound to my router, but what I am doing is using a web browser. I have bookmarks for the various things that I want to do via port knock, and just select each bookmark, one after another. It's low tech, but it works.

I install the mAP on the customer site to give me a gateway to access equipment behind it. So for sites that don't have a blocking firewall configuring wireguard is a piece of cake. But for this one I need a way to tunnel through that third party firewall hence my desire to initiate port knocking from a Mikrotik router to another Mikrotik router.

I'm trying to get around a 3rd-party firewall that blocks non HTTP traffic.

See https://github.com/shadowsocks/v2ray-plugin. Put this inside container and use port knocking to open https port. This build works on ROS container: https://hub.docker.com/r/teddysun/go-shadowsocks2

Edit:
I see you have device with architecture that doesn't support containers (MIPSBE), if you have same mAP on your side where you run wireguard, bad luck, you will need to attach another device on network to setup that. On client side - computer inside firewall, setup shadowsocks client which will run local socks proxy that can you use for any L3 connection outside firewall. Tunneling which shadowsocks is supported with its ss-tunnel tool.
On client side is also possible to create socks tunneling interface https://danstechjourney.com/posts/socks ... interface/ with routing over it so you don't need to setup proxy for applications connections and OS, also proxychains https://github.com/haad/proxychains can be used for that.

Thank you but none of this answers my question. Is there a way to perform a "knock" from within RouterOS?

And I'm having difficulties working with the corporate firewall administration. I'm hoping they'll approve opening the ports I need but even if they do it's made me think about how I can safeguard for the future.

the obvious question is : who are you and what is your relationship with the company?

if you are legit on their side - i don't think you will post this question in the first place.

Obviously I'm a nefarious character up to no good.

I'm a vendor contracted to provide a service which requires internet access. The customer has either a 3rd party or separate corporate department (unclear to me at this time) that administers the firewall. The service I provide is both requested by and necessary for the customer. However, since the firewall modification is going to require requests relayed through at least two levels something is likely to be lost in translation.

Because the service is necessary I know eventually the ports I need will be opened. This does not negate my question.

Is there a way to generate a port knock from within RouterOS?

Port knocking on TCP ports is as easy as using /tool fetch url="http://ip.to.be.knocked:port-to-be-knocked/some-bogus-file-name", and port knocking on UDP ports is as easy as using resolve some.bogus.string.with.dots server=ip.to.be.knocked port=port-to-be-knocked. But there are limitations - to restrict the number of packets that will be sent, you have to create some firewall rules in the output chain.

Other than that - even strict firewall administrators often permit access to TCP/8443.

Is there a way to generate a port knock from within RouterOS?

even if there is port knocking in MT or in other vendors - your question description is too obvious that the company simply don't trust you, be it other vendors resident engineer who stayed there to run the security subsection nor local operator.

so, in simple way - maybe they just hesitate to show you the exit door.

just a thought. good luck

your question description is too obvious that the company simply don't trust you

You seem to have been lucky so far to only meet customers that are small enough and/or competent enough that setting up remote access for contractors is a fast process. Believe me or not, it is not always the case

@ sindy

thank you for your compliment

Believe me or not, it is not always the case

having difficulty in market penetration, doesn't mean you have to push your luck to the edge.

and, as far as experience concerned - either the op doesn't have that promising look or just can't compete with others - in fair context of course.

simply put, that is how competition works in systems integration nor any other disciplines.

any way, yes - agreed. port knocking is nice. but unfortunately it doesn't have the industry compliance standard yet.

so, as a contractor - you should know better .

agreed, maybe there are hard potential customers - but we should respect them as well.

Thank you but none of this answers my question. Is there a way to perform a "knock" from within RouterOS?

Yes, sry I misread OT, you can use fetch tool on ROS and send some "secret" data in http-data to with http-method post to port 80. Using Layer7 protocol in firewall rule you can parse / verify that data and then add source to expiring address list, similar to this https://wiki.mikrotik.com/wiki/Port_Knocking.
Edit: you can't send tcp data until connection is established, only SYN packets can be filtered if port is closed.
Edit2: maybe this still will be possible to knock with "secret" data on ROS using traffic generator with injected pcap file which contains packets for udp connection to destination port 53 with secret data

I am with Wise route on this thread.
Get the permissions done, and stop playing hacker in a network you have no business mucking about in.
Does the customer realize they could lose their connection and business and reputation??

Domotz has been a solid answer for us for years.

Zerotier running on one of the switches has allowed us to remote into OUR NETWORK SPACE INSIDE another network. When the IT guy didn't know how or want to had us a public IP or port or anything.

Port knocking on TCP ports is as easy as using /tool fetch url="http://ip.to.be.knocked:port-to-be-knocked/some-bogus-file-name", and port knocking on UDP ports is as easy as using resolve some.bogus.string.with.dots server=ip.to.be.knocked port=port-to-be-knocked. But there are limitations - to restrict the number of packets that will be sent, you have to create some firewall rules in the output chain.

Other than that - even strict firewall administrators often permit access to TCP/8443.

This...is extraordinarily helpful and precisely what I was asking for. Thank you.
Can you give me an example of an appropriate output rule?

Can you give me an example of an appropriate output rule?

If you want exactly one packet, and the output and postrouting chains are currently empty in all tables, it would be something like
/ip firewall filter add chain=output dst-address-list=packet-already-sent protocol=tcp-or-udp dst-port=port-to-be-knocked action=drop
/ip firewall mangle add chain=postrouting dst-address=ip.to.be.knocked protocol=tcp-or-udp dst-port=port-to-be-knocked action=add-dst-to-address-list address-list=packet-already-sent address-list-timeout=1m
For TCP, this would restrict the traffic to a single SYN packet, which may not be really practical, the method suggested by @optio in post #12 seems more useful to me. To allow more packets per attempt, you may use dst-limit matching to delay adding the destination address to the address list. You have to find out yourself how many attempts resolve and fetch use before giving up.

In larger companies, a pool of public addresses is sometimes used for src-nat, so the port knock may arrive from a different address than the actual SSTP connection attempt.

I also think it might be possible to distinguish an incoming SSTP connection attempt from an incoming HTTPS request using connection-bytes match condition together with tcp-flags=fin - a failed SSTP connection should always yield the same number of bytes, so if the customer only uses a single public address, such a failed connection attempt could be used to add the source to an address list used by the dst-nat rule redirecting incoming connections to 443 to the port where the SSTP server is listening. I.e. the first failed attempt would play the role of the port knock.

In larger companies, a pool of public addresses is sometimes used for src-nat, so the port knock may arrive from a different address than the actual SSTP connection attempt.

When sending some defined data in udp payload using layer7 protocol in filter it is possible to parse content and add src address if matched to allow list (with some dst-limit rule to be sure).
Eg. rule for udp 53 and dst-limit with mode dst-address-and-port can jump into some custom defined chain, second rule with layer7 protocol can try to match udp data from that chain and put src address into allow list.
There is a chance when sending multiple udp payloads with traffic generator in some period with same data that it can get all src addresses from pool but that isn't certain, depends how big is pool and how is balanced.

There is a chance when sending multiple udp payloads with traffic generator in some period with same data...

This idea is great! Given the timeouts, it may take quite long (minutes) to collect them all, but on the other hand, as this is not port knocking per se (the purpose here is not to only allow incoming connections within a few seconds after the knock), this may not be important.

I also think it might be possible to distinguish an incoming SSTP connection attempt from an incoming HTTPS request using connection-bytes match condition together with tcp-flags=fin

I've done some sniffing and it looks promising. Using different certificates for the HTTPS and for the SSTP should make the distinction even easier as if the SSTP client is unable to verify the server certificate, it terminates the connection sooner so the distinction might be more reliable even if the exact number of bytes changes after some RouterOS upgrade.