Can connect (telnet, dovecot etc) to my own server from an external network but not when I am on the same lan
I have a server (mail - postfix+dovecot, web - apache) on a kvm guest where
the host is on a local network behind a normal router (zte or whatever the ISP provided).
KVM guest has an IP on the same subnet as the host. (wicked+network bridge on host)
All works well if I try to access things while the client resides outside the LAN (like mobile on 4g link, or a completely different network).
Problem is that when I try to connect while the client is logged on the same network as the server, it just times out.
So far I have disabled all firewalls and tried it... no luck.
All port forwarding on the router works well as everything is accessible from outside.
Any ideas? What can I try to see what actually goes wrong or where it gets stuck.
Dovecot calls don't even get logged on the server, nor any packets seem to reach the server while the client is on the local network.
Apache works though, I can see the website while being on the local network, even though from the same computer I can't telnet the server on port 80 or 443.
networking virtual-machine dns postfix dovecot
asked Dec 11 '18 at 14:55
Boirebista
11
add a comment |
I have a server (mail - postfix+dovecot, web - apache) on a kvm guest where
the host is on a local network behind a normal router (zte or whatever the ISP provided).
KVM guest has an IP on the same subnet as the host. (wicked+network bridge on host)
All works well if I try to access things while the client resides outside the LAN (like mobile on 4g link, or a completely different network).
Problem is that when I try to connect while the client is logged on the same network as the server, it just times out.
So far I have disabled all firewalls and tried it... no luck.
All port forwarding on the router works well as everything is accessible from outside.
Any ideas? What can I try to see what actually goes wrong or where it gets stuck.
Dovecot calls don't even get logged on the server, nor any packets seem to reach the server while the client is on the local network.
Apache works though, I can see the website while being on the local network, even though from the same computer I can't telnet the server on port 80 or 443.
networking virtual-machine dns postfix dovecot
asked Dec 11 '18 at 14:55
Boirebista
11
wiki.mikrotik.com/wiki/Hairpin_NAT is one technical explanation of what probably goes wrong in your case.
– grawity
Dec 11 '18 at 16:45
add a comment |
I have a server (mail - postfix+dovecot, web - apache) on a kvm guest where
the host is on a local network behind a normal router (zte or whatever the ISP provided).
KVM guest has an IP on the same subnet as the host. (wicked+network bridge on host)
All works well if I try to access things while the client resides outside the LAN (like mobile on 4g link, or a completely different network).
Problem is that when I try to connect while the client is logged on the same network as the server, it just times out.
So far I have disabled all firewalls and tried it... no luck.
All port forwarding on the router works well as everything is accessible from outside.
Any ideas? What can I try to see what actually goes wrong or where it gets stuck.
Dovecot calls don't even get logged on the server, nor any packets seem to reach the server while the client is on the local network.
Apache works though, I can see the website while being on the local network, even though from the same computer I can't telnet the server on port 80 or 443.
networking virtual-machine dns postfix dovecot
asked Dec 11 '18 at 14:55
Boirebista
11
I have a server (mail - postfix+dovecot, web - apache) on a kvm guest where
the host is on a local network behind a normal router (zte or whatever the ISP provided).
KVM guest has an IP on the same subnet as the host. (wicked+network bridge on host)
All works well if I try to access things while the client resides outside the LAN (like mobile on 4g link, or a completely different network).
Problem is that when I try to connect while the client is logged on the same network as the server, it just times out.
So far I have disabled all firewalls and tried it... no luck.
All port forwarding on the router works well as everything is accessible from outside.
Any ideas? What can I try to see what actually goes wrong or where it gets stuck.
Dovecot calls don't even get logged on the server, nor any packets seem to reach the server while the client is on the local network.
Apache works though, I can see the website while being on the local network, even though from the same computer I can't telnet the server on port 80 or 443.
networking virtual-machine dns postfix dovecot
networking virtual-machine dns postfix dovecot
asked Dec 11 '18 at 14:55
Boirebista
11
asked Dec 11 '18 at 14:55
Boirebista
11
asked Dec 11 '18 at 14:55
Boirebista
11
asked Dec 11 '18 at 14:55
Boirebista
11
asked Dec 11 '18 at 14:55
Boirebista
11
11
wiki.mikrotik.com/wiki/Hairpin_NAT is one technical explanation of what probably goes wrong in your case.
– grawity
Dec 11 '18 at 16:45
add a comment |
wiki.mikrotik.com/wiki/Hairpin_NAT is one technical explanation of what probably goes wrong in your case.
– grawity
Dec 11 '18 at 16:45
wiki.mikrotik.com/wiki/Hairpin_NAT is one technical explanation of what probably goes wrong in your case.
– grawity
Dec 11 '18 at 16:45
wiki.mikrotik.com/wiki/Hairpin_NAT is one technical explanation of what probably goes wrong in your case.
– grawity
Dec 11 '18 at 16:45
add a comment |
1 Answer
1
active
oldest
votes
What happens?
Your client is most likely trying to connect to the public IP of your ISP.
Most consumer modem/routers do not support loopback connections.
So what basically happens is that the request is sent to the modem, the modem sees an IP Address that is not in the DHCP scope of the router and thinks: Oh, this is for the internet. It sends out the request to the ISP that immediately sends it back.
The modem is sending out the traffic on that moment so the port is occupied and as such the connection times out.
On a loopback supported device, the modem is smart enough to understand the request was meant for itself and forwards the connection based on the port forwarding ruleset.
How to solve?
What you need to do is ask your client to not use the public ip address, but the local ip address instead.
Lets say your public ip address is: 123.45.67.89 and the port forwarding is set to redirect port 1234 to ip: 192.168.0.1, then instead of using 123.45.67.89, the client would need to connect to 192.168.0.1.
answered Dec 11 '18 at 15:32
LPChip
35.3k55084
Indeed that works.. but that would mean on my mobile, I have to have 2 accounts setup for the same email account. First that calls the mail server as mail.example.com and the other account that calls the mail server as 192.168.0.83 or whatever the local ip is. Any smarter serverside workaround available? Maybe a local DNS or something? I don't know much about those but I'm just throwing it in here.
– Boirebista
Dec 11 '18 at 16:25
Well, yes, the necessary feature is called "loopback", but... Your description of "what actually happens" is way off the rails. IP routing isn't based on DHCP scopes; hosts and routers always recognize packets sent to their own IP address – that's not what "NAT loopback" is about; the port isn't "occupied" because the packet has already been sent before the ISP receives it; and the problem has nothing to do with it being occupied anyway – even if you assume a half-duplex link (unlike e.g. full-duplex Ethernet), the incoming packets will merely get buffered for a bit.
– grawity
Dec 11 '18 at 16:38
@Boirebista: Yes, local DNS is the easiest way to implement LPChip's suggestion. Outside the network,mail.example.compoints to the public address, but inside, your local DNS server overrides the reply with the internal address instead. Works regardless of router and doesn't have the issues that hairpin/loopback NAT would cause.
– grawity
Dec 11 '18 at 16:49
@grawity Thanks. Guess I better start figuring out bind... had a few attempts at it but usually I managed to break everything with it. Thanks for pointing to the proper way. Upside is that it is good to learn something as well
– Boirebista
Dec 11 '18 at 17:12
@Boirebista: If your domain is already hosted from inside the LAN via Bind, use Bind's "views". If it's hosted externally and you only want to override some parts locally, easier to use Unbound.
– grawity
Dec 11 '18 at 17:20
|
show 1 more comment
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1382655%2fcan-connect-telnet-dovecot-etc-to-my-own-server-from-an-external-network-but%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
What happens?
Your client is most likely trying to connect to the public IP of your ISP.
Most consumer modem/routers do not support loopback connections.
So what basically happens is that the request is sent to the modem, the modem sees an IP Address that is not in the DHCP scope of the router and thinks: Oh, this is for the internet. It sends out the request to the ISP that immediately sends it back.
The modem is sending out the traffic on that moment so the port is occupied and as such the connection times out.
On a loopback supported device, the modem is smart enough to understand the request was meant for itself and forwards the connection based on the port forwarding ruleset.
How to solve?
What you need to do is ask your client to not use the public ip address, but the local ip address instead.
Lets say your public ip address is: 123.45.67.89 and the port forwarding is set to redirect port 1234 to ip: 192.168.0.1, then instead of using 123.45.67.89, the client would need to connect to 192.168.0.1.
answered Dec 11 '18 at 15:32
LPChip
35.3k55084
Indeed that works.. but that would mean on my mobile, I have to have 2 accounts setup for the same email account. First that calls the mail server as mail.example.com and the other account that calls the mail server as 192.168.0.83 or whatever the local ip is. Any smarter serverside workaround available? Maybe a local DNS or something? I don't know much about those but I'm just throwing it in here.
– Boirebista
Dec 11 '18 at 16:25
Well, yes, the necessary feature is called "loopback", but... Your description of "what actually happens" is way off the rails. IP routing isn't based on DHCP scopes; hosts and routers always recognize packets sent to their own IP address – that's not what "NAT loopback" is about; the port isn't "occupied" because the packet has already been sent before the ISP receives it; and the problem has nothing to do with it being occupied anyway – even if you assume a half-duplex link (unlike e.g. full-duplex Ethernet), the incoming packets will merely get buffered for a bit.
– grawity
Dec 11 '18 at 16:38
@Boirebista: Yes, local DNS is the easiest way to implement LPChip's suggestion. Outside the network,mail.example.compoints to the public address, but inside, your local DNS server overrides the reply with the internal address instead. Works regardless of router and doesn't have the issues that hairpin/loopback NAT would cause.
– grawity
Dec 11 '18 at 16:49
@grawity Thanks. Guess I better start figuring out bind... had a few attempts at it but usually I managed to break everything with it. Thanks for pointing to the proper way. Upside is that it is good to learn something as well
– Boirebista
Dec 11 '18 at 17:12
@Boirebista: If your domain is already hosted from inside the LAN via Bind, use Bind's "views". If it's hosted externally and you only want to override some parts locally, easier to use Unbound.
– grawity
Dec 11 '18 at 17:20
|
show 1 more comment
What happens?
Your client is most likely trying to connect to the public IP of your ISP.
Most consumer modem/routers do not support loopback connections.
So what basically happens is that the request is sent to the modem, the modem sees an IP Address that is not in the DHCP scope of the router and thinks: Oh, this is for the internet. It sends out the request to the ISP that immediately sends it back.
The modem is sending out the traffic on that moment so the port is occupied and as such the connection times out.
On a loopback supported device, the modem is smart enough to understand the request was meant for itself and forwards the connection based on the port forwarding ruleset.
How to solve?
What you need to do is ask your client to not use the public ip address, but the local ip address instead.
Lets say your public ip address is: 123.45.67.89 and the port forwarding is set to redirect port 1234 to ip: 192.168.0.1, then instead of using 123.45.67.89, the client would need to connect to 192.168.0.1.
answered Dec 11 '18 at 15:32
LPChip
35.3k55084
Indeed that works.. but that would mean on my mobile, I have to have 2 accounts setup for the same email account. First that calls the mail server as mail.example.com and the other account that calls the mail server as 192.168.0.83 or whatever the local ip is. Any smarter serverside workaround available? Maybe a local DNS or something? I don't know much about those but I'm just throwing it in here.
– Boirebista
Dec 11 '18 at 16:25
Well, yes, the necessary feature is called "loopback", but... Your description of "what actually happens" is way off the rails. IP routing isn't based on DHCP scopes; hosts and routers always recognize packets sent to their own IP address – that's not what "NAT loopback" is about; the port isn't "occupied" because the packet has already been sent before the ISP receives it; and the problem has nothing to do with it being occupied anyway – even if you assume a half-duplex link (unlike e.g. full-duplex Ethernet), the incoming packets will merely get buffered for a bit.
– grawity
Dec 11 '18 at 16:38
@Boirebista: Yes, local DNS is the easiest way to implement LPChip's suggestion. Outside the network,mail.example.compoints to the public address, but inside, your local DNS server overrides the reply with the internal address instead. Works regardless of router and doesn't have the issues that hairpin/loopback NAT would cause.
– grawity
Dec 11 '18 at 16:49
@grawity Thanks. Guess I better start figuring out bind... had a few attempts at it but usually I managed to break everything with it. Thanks for pointing to the proper way. Upside is that it is good to learn something as well
– Boirebista
Dec 11 '18 at 17:12
@Boirebista: If your domain is already hosted from inside the LAN via Bind, use Bind's "views". If it's hosted externally and you only want to override some parts locally, easier to use Unbound.
– grawity
Dec 11 '18 at 17:20
|
show 1 more comment
What happens?
Your client is most likely trying to connect to the public IP of your ISP.
Most consumer modem/routers do not support loopback connections.
So what basically happens is that the request is sent to the modem, the modem sees an IP Address that is not in the DHCP scope of the router and thinks: Oh, this is for the internet. It sends out the request to the ISP that immediately sends it back.
The modem is sending out the traffic on that moment so the port is occupied and as such the connection times out.
On a loopback supported device, the modem is smart enough to understand the request was meant for itself and forwards the connection based on the port forwarding ruleset.
How to solve?
What you need to do is ask your client to not use the public ip address, but the local ip address instead.
Lets say your public ip address is: 123.45.67.89 and the port forwarding is set to redirect port 1234 to ip: 192.168.0.1, then instead of using 123.45.67.89, the client would need to connect to 192.168.0.1.
answered Dec 11 '18 at 15:32
LPChip
35.3k55084
What happens?
Your client is most likely trying to connect to the public IP of your ISP.
Most consumer modem/routers do not support loopback connections.
So what basically happens is that the request is sent to the modem, the modem sees an IP Address that is not in the DHCP scope of the router and thinks: Oh, this is for the internet. It sends out the request to the ISP that immediately sends it back.
The modem is sending out the traffic on that moment so the port is occupied and as such the connection times out.
On a loopback supported device, the modem is smart enough to understand the request was meant for itself and forwards the connection based on the port forwarding ruleset.
How to solve?
What you need to do is ask your client to not use the public ip address, but the local ip address instead.
Lets say your public ip address is: 123.45.67.89 and the port forwarding is set to redirect port 1234 to ip: 192.168.0.1, then instead of using 123.45.67.89, the client would need to connect to 192.168.0.1.
answered Dec 11 '18 at 15:32
LPChip
35.3k55084
answered Dec 11 '18 at 15:32
LPChip
35.3k55084
answered Dec 11 '18 at 15:32
LPChip
35.3k55084
answered Dec 11 '18 at 15:32
LPChip
35.3k55084
35.3k55084
Indeed that works.. but that would mean on my mobile, I have to have 2 accounts setup for the same email account. First that calls the mail server as mail.example.com and the other account that calls the mail server as 192.168.0.83 or whatever the local ip is. Any smarter serverside workaround available? Maybe a local DNS or something? I don't know much about those but I'm just throwing it in here.
– Boirebista
Dec 11 '18 at 16:25
Well, yes, the necessary feature is called "loopback", but... Your description of "what actually happens" is way off the rails. IP routing isn't based on DHCP scopes; hosts and routers always recognize packets sent to their own IP address – that's not what "NAT loopback" is about; the port isn't "occupied" because the packet has already been sent before the ISP receives it; and the problem has nothing to do with it being occupied anyway – even if you assume a half-duplex link (unlike e.g. full-duplex Ethernet), the incoming packets will merely get buffered for a bit.
– grawity
Dec 11 '18 at 16:38
@Boirebista: Yes, local DNS is the easiest way to implement LPChip's suggestion. Outside the network,mail.example.compoints to the public address, but inside, your local DNS server overrides the reply with the internal address instead. Works regardless of router and doesn't have the issues that hairpin/loopback NAT would cause.
– grawity
Dec 11 '18 at 16:49
@grawity Thanks. Guess I better start figuring out bind... had a few attempts at it but usually I managed to break everything with it. Thanks for pointing to the proper way. Upside is that it is good to learn something as well
– Boirebista
Dec 11 '18 at 17:12
@Boirebista: If your domain is already hosted from inside the LAN via Bind, use Bind's "views". If it's hosted externally and you only want to override some parts locally, easier to use Unbound.
– grawity
Dec 11 '18 at 17:20
|
show 1 more comment
Indeed that works.. but that would mean on my mobile, I have to have 2 accounts setup for the same email account. First that calls the mail server as mail.example.com and the other account that calls the mail server as 192.168.0.83 or whatever the local ip is. Any smarter serverside workaround available? Maybe a local DNS or something? I don't know much about those but I'm just throwing it in here.
– Boirebista
Dec 11 '18 at 16:25
Well, yes, the necessary feature is called "loopback", but... Your description of "what actually happens" is way off the rails. IP routing isn't based on DHCP scopes; hosts and routers always recognize packets sent to their own IP address – that's not what "NAT loopback" is about; the port isn't "occupied" because the packet has already been sent before the ISP receives it; and the problem has nothing to do with it being occupied anyway – even if you assume a half-duplex link (unlike e.g. full-duplex Ethernet), the incoming packets will merely get buffered for a bit.
– grawity
Dec 11 '18 at 16:38
@Boirebista: Yes, local DNS is the easiest way to implement LPChip's suggestion. Outside the network,mail.example.compoints to the public address, but inside, your local DNS server overrides the reply with the internal address instead. Works regardless of router and doesn't have the issues that hairpin/loopback NAT would cause.
– grawity
Dec 11 '18 at 16:49
@grawity Thanks. Guess I better start figuring out bind... had a few attempts at it but usually I managed to break everything with it. Thanks for pointing to the proper way. Upside is that it is good to learn something as well
– Boirebista
Dec 11 '18 at 17:12
@Boirebista: If your domain is already hosted from inside the LAN via Bind, use Bind's "views". If it's hosted externally and you only want to override some parts locally, easier to use Unbound.
– grawity
Dec 11 '18 at 17:20
Indeed that works.. but that would mean on my mobile, I have to have 2 accounts setup for the same email account. First that calls the mail server as mail.example.com and the other account that calls the mail server as 192.168.0.83 or whatever the local ip is. Any smarter serverside workaround available? Maybe a local DNS or something? I don't know much about those but I'm just throwing it in here.
– Boirebista
Dec 11 '18 at 16:25
Indeed that works.. but that would mean on my mobile, I have to have 2 accounts setup for the same email account. First that calls the mail server as mail.example.com and the other account that calls the mail server as 192.168.0.83 or whatever the local ip is. Any smarter serverside workaround available? Maybe a local DNS or something? I don't know much about those but I'm just throwing it in here.
– Boirebista
Dec 11 '18 at 16:25
Well, yes, the necessary feature is called "loopback", but... Your description of "what actually happens" is way off the rails. IP routing isn't based on DHCP scopes; hosts and routers always recognize packets sent to their own IP address – that's not what "NAT loopback" is about; the port isn't "occupied" because the packet has already been sent before the ISP receives it; and the problem has nothing to do with it being occupied anyway – even if you assume a half-duplex link (unlike e.g. full-duplex Ethernet), the incoming packets will merely get buffered for a bit.
– grawity
Dec 11 '18 at 16:38
Well, yes, the necessary feature is called "loopback", but... Your description of "what actually happens" is way off the rails. IP routing isn't based on DHCP scopes; hosts and routers always recognize packets sent to their own IP address – that's not what "NAT loopback" is about; the port isn't "occupied" because the packet has already been sent before the ISP receives it; and the problem has nothing to do with it being occupied anyway – even if you assume a half-duplex link (unlike e.g. full-duplex Ethernet), the incoming packets will merely get buffered for a bit.
– grawity
Dec 11 '18 at 16:38
@Boirebista: Yes, local DNS is the easiest way to implement LPChip's suggestion. Outside the network,
mail.example.com points to the public address, but inside, your local DNS server overrides the reply with the internal address instead. Works regardless of router and doesn't have the issues that hairpin/loopback NAT would cause.– grawity
Dec 11 '18 at 16:49
@Boirebista: Yes, local DNS is the easiest way to implement LPChip's suggestion. Outside the network,
mail.example.com points to the public address, but inside, your local DNS server overrides the reply with the internal address instead. Works regardless of router and doesn't have the issues that hairpin/loopback NAT would cause.– grawity
Dec 11 '18 at 16:49
@grawity Thanks. Guess I better start figuring out bind... had a few attempts at it but usually I managed to break everything with it. Thanks for pointing to the proper way. Upside is that it is good to learn something as well
– Boirebista
Dec 11 '18 at 17:12
@grawity Thanks. Guess I better start figuring out bind... had a few attempts at it but usually I managed to break everything with it. Thanks for pointing to the proper way. Upside is that it is good to learn something as well
– Boirebista
Dec 11 '18 at 17:12
@Boirebista: If your domain is already hosted from inside the LAN via Bind, use Bind's "views". If it's hosted externally and you only want to override some parts locally, easier to use Unbound.
– grawity
Dec 11 '18 at 17:20
@Boirebista: If your domain is already hosted from inside the LAN via Bind, use Bind's "views". If it's hosted externally and you only want to override some parts locally, easier to use Unbound.
– grawity
Dec 11 '18 at 17:20
|
show 1 more comment
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1382655%2fcan-connect-telnet-dovecot-etc-to-my-own-server-from-an-external-network-but%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
wiki.mikrotik.com/wiki/Hairpin_NAT is one technical explanation of what probably goes wrong in your case.
– grawity
Dec 11 '18 at 16:45