Cannot issue/renew TLS certificate if interactsh-server can't query own public IP

[pielgrzym]

Hi,

I have a specific interact server setup. My machine is behind NAT and firewall is performing 1:1 NAT for public IP from my RIPE. This setup works almost like an external IP but with one exception - the machine can't query it's own public IP. This prevents Interactsh-server from successfully finishing letsencrypt challenge-response.

Interactsh version: 1.0.5

Current Behavior:

When trying to obtain a certificate the request times out: waiting for solver certmagic.solverWrapper to be ready: checking DNS propagation of _acme-challenge.MYDOMAIN.xyz: dial tcp MYPUBLICIP:53: i/o timeout

Here is my server invocation: interactsh-server -domain MYDOMAIN.xyz -ip MYPUBLICIP -token the_token -wc

I tried using -lip option to point to local server IP, but same result: interactsh-server -domain MYDOMAIN.xyz -ip MYPUBLICIP -token the_token -wc -lip 172.16.0.2

Here is debug output:

{"level":"error","ts":1657543919.3003702,"logger":"obtain","caller":"[email protected]/config.go:553","msg":"could not get certificate from issuer","identifier":"*.MYDOMAIN.xyz","issuer":"acme-v02.api.letsencrypt.org-directory","error":"[*.MYDOMAIN.xyz] solving challenges: waiting for solver certmagic.solverWrapper to be ready: checking DNS propagation of _acme-challenge.MYDOMAIN.xyz: dial tcp MYPUBLICIP:53: i/o timeout (order=https://acme-v02.api.letsencrypt.org/acme/order/REMOVED/REMOVED) (ca=https://acme-v02.api.letsencrypt.org/directory)","stacktrace":"github.com/caddyserver/certmagic.(*Config).obtainCert.func2\n\t/root/go/pkg/mod/github.com/caddyserver/[email protected]/config.go:553\ngithub.com/caddyserver/certmagic.(*Config).obtainCert\n\t/root/go/pkg/mod/github.com/caddyserver/[email protected]/config.go:590\ngithub.com/caddyserver/certmagic.(*Config).ObtainCertSync\n\t/root/go/pkg/mod/github.com/caddyserver/[email protected]/config.go:437\ngithub.com/projectdiscovery/interactsh/pkg/server/acme.HandleWildcardCertificates\n\t/root/go/pkg/mod/github.com/projectdiscovery/[email protected]/pkg/server/acme/acme_certbot.go:64\nmain.main\n\t/root/go/pkg/mod/github.com/projectdiscovery/[email protected]/cmd/interactsh-server/main.go:208\nruntime.main\n\t/usr/local/go/src/runtime/proc.go:255"}
{"level":"info","ts":1657543919.3004422,"logger":"obtain","caller":"[email protected]/config.go:477","msg":"releasing lock","identifier":"*.MYDOMAIN.xyz"}

Expected Behavior:

Generating certificate ;)

Steps To Reproduce:

1. Prevent accessing own public IP from given host
2. Start intearctsh-server and wait for certificate generation

Anything else:

• I can successfuly query challenge TXT record from outside the network
• everything works with certificates generated with much older interactsh-server version (using -cert and -privkey options)

EDIT

I double checked with some extremely ugly firewall workarounds that on the same machine everything works perfect when the machine can access it's own public IP :)

[ehsandeep]

@pielgrzym

everything works perfect when the machine can access it's own public IP.

Yes, it is required to have access to public IP in order to use interactsh server publicly, otherwise failing is expected.

if that's the case, don't think it's an issue with the server or do you intend to use interactsh internally only?

[pielgrzym]

This usecase is confusing :) the server has public IP. Anyone can query this public IP and all the traffic will be arp-proxied to an IP inside LAN. From the outside things look exactly the same way as if the server had a regular external IP. Origin of the traffic is key - if the traffic originates from the server itself it is not looped back (so if I have server with public IP 1.2.3.4 and private IP 172.16.0.2 doing 'curl 1.2.3.4' anywhere from internet will work, but same curl ran inside the server will timeout). So letsencrypt can query the TXT record, but intearctsh-server is trying for some reasone to access TCP/53 by issuing a connection to it's public IP and this times out :)

This is a specific usecase, it would be nice however to have a workaround :)

[tiago-nss]

I also have the same issue when the host is behind nat, and i'm using a sub domain to point to interactsh eg: fu.some.zyz same issue happens, this started to happen after 0.0.7.

[ehsandeep]

This usecase is confusing :) the server has public IP. Anyone can query this public IP and all the traffic will be arp-proxied to an IP inside LAN. From the outside things look exactly the same way as if the server had a regular external IP. Origin of the traffic is key - if the traffic originates from the server itself it is not looped back (so if I have server with public IP 1.2.3.4 and private IP 172.16.0.2 doing 'curl 1.2.3.4' anywhere from internet will work, but same curl ran inside the server will timeout). So letsencrypt can query the TXT record, but intearctsh-server is trying for some reasone to access TCP/53 by issuing a connection to it's public IP and this times out :)

This is a specific usecase, it would be nice however to have a workaround :)

Thanks for providing detailed context, by any chance do you have any information on how to configure / or any cloud provider that comes with this environment for testing?

[Mzack9999]

certmagic requires dialing the root DNS servers' public IP internally to ensure that the ACME challenge propagated correctly. Any reason why the box can't be configured to communicate externally and get its own traffic back via NAT?

[pielgrzym]

I see, I don't think that working around this issue is worth it. I'd just leave a notice in the documentation for people with poor network setup. Sorry guys for bothering you. @ehsandeep I don't think any cloud provicer will allow for such atypical setup - I achieved this on my own pfsense and ripe network. I can leave detailed instructions how to set it up on pfsense if you like :)

[rs-loves-bugs]

do you have any information on how to configure / or any cloud provider that comes with this environment for testing?

You can reproduce this issue on the free tier of Oracle Cloud with a typical default setup(firewall disabled both on the instance and web console).

Is there other information I can help with?

An error occurred while applying for a certificate, error: [*.example.com] Obtain: [*.example.com] solving challenges: waiting for solver certmagic.solverWrapper to be ready: checking DNS propagation of "_acme-challenge.example.com": dial tcp: lookup ns1.example.com.: i/o timeout (order=https://acme-v02.api.letsencrypt.org/acme/order/835874867/146419738087) (ca=https://acme-v02.api.letsencrypt.org/directory)

[Mzack9999]

Marking as complete - It seems like there isn't a lot we can do as the verification mechanism requires the external verifier to query the interactsh server