From internal, I can’t seem to access my external domain from internal. It just times out.
I believe this has something todo with my 2 WAN connections (pppoe-out1 and pppoe-out2). If I set the DNS on my domain to the IP of pppoe-out1, everything seems to work fine. If I set the DNS to the IP on pppoe-out2, it does not.
On both my WAN IP’s (1.1.1.1 and 1.1.1.2) can access the ports I’m forwarding. I want to 1-to-1 nat a public IP to an internal source being able to access everything internally and externally by that IP (i.e. 1.1.1.2). 1.1.1.1, would or could be a separate box internally.
I am able (from external) to access my domain which has its dns pointed to 174.xx.80.6 (which is held by the ‘synology’ pppoe-client). I’m accessing it from my cellular connected phone and able to access tcp/port 80. If I’m on the 192.168.2.0/24 network, I get a ERR_CONNECTION_REFUSED. Do I need a filter rule of some sort? There is no firewall on the 192.168.2 box (it works externally).
pppoe-out1 and devbox are other interfaces (both pppoe-clients).
# ADDRESS NETWORK INTERFACE
0 192.168.2.1/24 192.168.2.0 ether2
1 D 76.XX.52.186/32 10.11.7.113 pppoe-out1
2 D 184.XX.11.243/32 10.11.7.113 devbox
3 D 174.XX.80.6/32 10.11.7.113 synology
UPDATE: I was using https not http. If I use http I get the RouterOS page instead of my website (so its just hitting the router). externally it works.
Dont you need some routing rules. It appears as though you are settin up permitting such traffic by rules but not telling the traffic where to go formally?
What happens is that the client request comes to the IP address of the WAN2, is dst-nated to the IP address of the server on the LAN and delivered there. However, the response of the server uses the routing rules which do not use WAN2 as gateway, so the response is sent out via WAN1. I’m not sure whether it is sent out with the source address of WAN2 and thus the ISP doesn’t let it through, or whether it is sent with the source address of WAN1 so the client doesn’t accept it, but the result is effectively the same in both cases.
So what you need to do is to use connection-marking and routing-marking, so that requests which came from outside to WAN2’s address would be responded via WAN2 and requests which came to WAN1’s address would be responded via WAN1.
I gathered that as well. I put a sniffer on ‘devbox’ (my secondary pppoe interface), and performed a ping. I see the ping (dst 8.8.8.8, src 174.xx.83.83). This tells me the connection marking and routing is working. I also see the nat rule (Outbound NAT for 192.168.2.4) working. However, the packets never arrive back to the .2.4 box. I added a dst-nat, but still no luck.
I’m afraid I’m a bit lost in your setup. Instead of connection-marking only the initial packet of each connection, you connection-mark every packet sent by 192.168.2.4; well, for testing that may work (unless you have fasttracking enabled), but for real operation, you would have to connection-mark initial packets which arrive through one of the WAN interfaces so that the responses would be routed out through the same interface through which the requests came in.
Now you say that the response never comes back to 192.168.2.4, so I assume you ping from 192.168.2.4. But your problem is that you assign routing-marks also to packets coming from WAN2 towards the 192.168.2.4, which causes these packets to be routed out via WAN2 again because there is no route with routing-mark=devbox-rm which would lead to 192.168.2.4. So either add “dst-address=!192.168.2.4” to the action=mark-routing rule, or add a route dst-address=192.168.2.4/32 routing-mark=devbox-rm gateway=the-lan-inteface. Of course these exceptions should actually span all LAN subnets, I just don’t know them so I refer to 192.168.2.4.
I am lost.
The request was made for outgoing traffic from the LAN that was solved.
If you have external folks are coming in on the wrong WAN ISP that is the fault of the OP for giving folks the wrong WANIP address or DYDNS name.
Well, I read the OP as the usual requirement to be able to access the Mikrotik itself or the dst-nat’ed server(s) on its LAN via any of the Mikrotik’s WAN addresses, which makes sense in various scenarios.
Only the test method the OP has chosen is a bit upside down here (pinging a device in the internet from a device on LAN instead of sending a http request from the internet), but that doesn’t matter as it was enough to highlight the issue with assigning routing-marks to packets with dst-addresses of devices on the LAN side.
Hairpin NAT is only necessary when you need the clients in a given LAN subnet to contact the server in the very same LAN subnet via the WAN address of the router (e.g. because the server’s domain name is resolved to the WAN address and you need to use the domain name in the url). As the OP hasn’t mentioned such need, I don’t see any need to configure hairpin NAT.
But maybe I didn’t get the essence of your question?