0

I have a Mikrotik 750 router. I have an SVN server set up to run over https on server 192.168.1.111. I am going to have multiple machines using the standard ssl port so I decided to use port forwarding. From outside the firewall something would hit my public ip via svn.mydomain.com:5555 and it would forward to my machine 192.168.1.111:443

Using Rule:

chain=dstnat action=dst-nat to-addresses=192.168.1.111 to-ports=443 
 protocol=tcp in-interface=ether1-gateway dst-port=5555

Everything works fine until I try use SVN behind the firewall. Of course I can access the server directly; however, that would mean changing the configuration every time I want to commit as I work from in and out of the network. I would rather be able to hit svn.mydomain.com:5555 from behind the firewall. What rule am I missing?

Edit:Rules added

Note: I'm using master/slave configuration

;;; hairpin rule (not sure if to port is causing problems) 
chain=srcnat action=masquerade to-ports=443 protocol=tcp 
  src-address=192.168.1.0/24 dst-address=192.168.1.111
  out-interface=ether2-master-local dst-port=5555

;;; another rule I tried
chain=dstnat action=dst-nat to-addresses=192.168.1.111 to-ports=443 
  protocol=tcp dst-address=192.168.1.111 dst-address-type=local 
  in-interface=ether2-master-local dst-port=5555
1

Based on the rule you posted, it only applies to packets coming from ether1-gateway. Which means that Mikrotik will never port-forward your packets when they are coming from your LAN (assuming it's on a different interface).

Now, the problem is that even if you change the rule to also apply to packets coming from your LAN, it still wouldn't work.

Let's say your workstation IP is 192.168.1.200 and you make a request to svn.mydomain.com:5555. That means that svn.mydomain.com will resolve to your public IP (assuming that this IP is on the mikrotik itself) and the request packets will leave your workstation with a source address of 192.168.1.200 and a destination address your public ip.

Now Mikrotik will match those packets and try to port-forward them to 192.168.1.111:443.
192.168.1.111 will happily accept then packets, process them and then send a reply to the source address 192.168.1.200.

And here starts the problem. Your workstation send the packets to your public IP, but the replies are coming from an 'unknown' IP (as far as your workstation is concerned) thus it simply drops them.
What you need is the packets coming back from the public IP not 192.168.1.111.

So in order for this to work you need to add an extra src-nat rule after the one you already made on your mikrotik that will match and do the following:

  • If the source address is your LAN subnet
  • And the destination address and port are 192.168.1.111:443
  • Then do a src-nat and set the IP address to the Mikrotik's address (say for example 192.168.1.1).

This way the SVN server will send the replies back to mikrotik and Mikrotik will send the replies back to your workstation with the public IP as the source address and everything should work ok.

Now take into consideration that with this method, all the requests coming to the SVN server from your LAN will have the source IP of Mikrotik instead of the actual PC that made the request. So all the logs will only show Mikrotik's IP.

Depending on your setup and amount of users this might not work for you.

So another approach would be to simply add on your hosts file the following:
192.168.1.111 svn.mydomain.com and reconfigure your SVN server to also listen to port 5555.

Or if your LAN uses Mikrotik as the DNS server you could simple add a static dns record on Mikrotik (/ip dns static) so that every PC on your LAN would resolve svn.mydomain.com to the internal IP while everyone else outside your LAN will resolve to the public IP as before.

2
  • Thanks for the tips and explanation. I like your host file idea and listening on the other port but, unless I'm misunderstanding, that would still be a problem outside of LAN as it would try to connect 192.168.1.111 on someone else's network. I may give the local DNS a shot. I tried playing with more rules after reading about hairpin NATs which I'll add to the question.
    – bryjohns
    Jul 7 '15 at 22:46
  • Essentially what I've described is Hairpin NAT. The disadvantage with Hairpin is that you lose the real source IP of the requests to your SVN server. Other than that it should work without any other changes (dns, hosts file, etc) on your network.
    – Cha0s
    Jul 8 '15 at 10:07

Not the answer you're looking for? Browse other questions tagged or ask your own question.