Let´s to say there is a network very limited in opened ports, just 22, 21 80 and maybe 8080. I want to stablish any kind of VPN between two routers. But using L2TP for example there is no way to coneect L2TP server on 1701 port!!
What should I do to change destiny port in L2TP client??
dst-nat does not perform any change in output or postrouting chain.
May be another solution? The client RouterBoard have not a Public IP, is behind a nat and the STRICT firewall
Sometimes more questions are needed before an answer is given.
Perhaps he has already tried to ask, or it’s not an option to ask?
How would I know this before he answers my question?
Perhaps others in the forum would be interested in an answer as well?
Yep that’s the basic idea of a forum. No prizes there I’m afraid.
Perhaps you could come down off your high “networking” horse and help out?
For starters I generally do help out where I can. However I do see a lot of people trying circumvent their respective ISPs restrictions and are blatantly transgressing their terms and conditions. If what the OP is trying to do is perfectly legal, then he will get the help here, however if it’s not legal then why would Mikrotik want to get their reputation muddied?
Perhaps you don’t know how to do it?
Maybe and maybe not. Considering your childish response, you’ll now never know.
Ok, then here is my justification for wanting to know if this is possible:
I live in a country which has a Telecommunications Monopoly which is out rightly blocking the following protocols:
PPTP, L2TP, IPSEC, VOIP (SIP, SKINNY, IAX), to prevent people from using VOIP or Tunneled VOIP. The LAW of the land states that what the Telecom company is doing is illegal, however, the Telecom company could care less about the law of the land because they have all the politicians in their pockets. So the law doesn’t get enforced, which leaves customers without many options with regards to using VOIP within the country.
One potential work around would be to tunnel L2TP or another UDP based tunnel (OpenVPN on linux would also be an option) on an alternate port.
eoip uses GRE correct? might be an option. I always thought there would be a way to use NAT / redirect to change the port of l2tp, but I never got it working, although I dind’t spend much time testing. Maybe thats still an option.
Hi, this post is very old but I need exactly the same configuration. I do not have a public IP, my internet is from a small local provider whom has few public IPs and does kind of a private network for their clients, something like CGNAT I guess. I talked to then and they can open a few ports for me, but I can not specify the port number, so… I need to run a VPN L2TP/IPSec with other then the original ports. Is it possible?
Hello,
I haven’t tried it yet (I’m sure I will), but there’s a nice solution for DNS port changing which might be applicable here as well.
Open this link and look for a post by “Sob”, which is based on an idea by “Sindy” (big credit to both):
viewtopic.php?t=116211
I’m using this solution now for splitting external DNS servers by zones.
Just think carefully about the encapsulation. You can have a plain L2TP (not recommended for lack of security), a plain IPsec (with its very specific approach to routing), L2TP tunneled inside IPsec (the standard way), and some people use IPsec tunneled inside L2TP.
And you need to redirect only the ports for the outer tunnel, because the ISP’s firewall cannot affect the packets in the inner tunnel. So:
in case of the unusual configuration where IPsec is tunneled via L2TP (or if you use L2TP alone), it is enough to dst-nat UDP port 1701 at both clients’ output (which requires the local tunnel workaround) and server’s input
in case of the standard configuration where L2TP is tunelled via IPsec, it is enough to dst-nat UDP ports 500 and 4500 at clients’ output and server’s input. If you set up the IPsec layer manually, it is possible to set an alternative of remote port 500 but not of local port 500 nor of port 4500 at either end, so it is probably less confusing to handle both ports at both ends using the dst-nat. But there is another caveat in this case - if by chance both the client and server run on public IP addresses, the IPsec layer chooses plain ESP as transport, and if the ISP’s firewall is as tight as you describe, ESP packets are very likely to be dropped too. If this is the case, you have to force src-nat at one end to that the IPsec stack would decide to tunnel the ESP via UDP on port 4500
