Hello every one,
I use a LGH5 to connect to my ISP. The LAN cable then goes to a set of Netgear Orbis in AP mode to provide wifi and ethernet access in home.
The connection to the ISP is ppoe and then a static IP is assigned. I also have setup a VPN connection on my router according to this guide. This connection assigns a dynamic IP. I have a list of IPs that should be access with my ppoe connection and the rest of traffic goes through VPN. I also run some services that require portforwarding. My firewall rules and routes are listed here
The port forwarding is really spotty and unreliable. It works and sometimes not. To get it to work again I try rebooting and disabling re-enabling these rules which seems to randomly cure the problem.
I can’t use port forwarding from my internal network. When I use the URL pointing to my external IP, the connection fails.
By the way I have also tried the following in masquerade, no luck.
As you effectively have two “logical WANs” (the physical one and the VPN one), you have to make sure that the responses from the internal server use the proper WAN (the one through which the reqeuests to that server came in). As you have only posted the part of you configuration which you think is relevant, it is impossible to say what is actually wrong. I’d recommend to follow the hint in my automatic signature below, analysis tends to provide better results than divination.
You force routing of anything that comes from the 192.168.12.0/24 subnet (which includes the server at 192.168.12.1) via the VPN “WAN”, except the single /22 destination subnet in address-list ppoe-destinations which you force via the PPPoE WAN. So if the client’s address is outside that subnet, the server response always goes via the VPN WAN regardless which way the client’s request came, so clients connecting to your PPPoE address get responses from the currently assigned VPN address which they ignore (or don’t get them at all because some stateful firewall in the VPN path drops them as it could not see the initial packet of the connection).
So the simplest way is to force the traffic from the server to any destination via the PPPoE connection or, if you need clients to connect to both public IPs, to use the complete connection-marking approach as explained here (read the last paragraph of the post first to synchronize the context).
you permit both the /interface pppoe-client and /interface pptp-client to add a default route to your routing table. Whereas the forwarded traffic from hosts connected to your LAN is routing-marked by the /ip firewall mangle rules in chain=prerouting, packets sent by Mikrotik itself are not handled by these rules (check this set of diagrams to see why), so they take one of the two routes added by the tunneling protocols. So first of all it is surprising for me that your pptp tunnel doesn’t break once it establishes, but the default route provided by pppoe-client probably wins in most or all cases (does /ip route print while VPN is up confirm this assumption?). Second, the dynamic DNS service of Mikrotik’s cloud associates with your fqdn the IP from which it has actually received the registration request. So as you haven’t been very clear about the “url representing your address”, I suppose that you expect the clients to come to public IP assigned by the pptp, but you register to the cloud DNS the other one.
If some of my assumptions are wrong, it’s because they are assumptions, taken in absence of relevant information in your posts.
This fixes the port forwarding problem. (The URL points to ppoe IP as it is static.)
so first problem solved.
The second problem is that I can’t use the same URL that works from outside. I should use the IP address to access 192.168.12.1:PORT from 192.168.12.0/24. how can I overcome this one?
You again expect us to know that you talk about the case when clients in your LAN connect to the fqdn which resolves to the public IP of the PPPoE instead of stating that clearly in the OP. “My clients” doesn’t necessarily mean “clients in my LAN”.
Now what happens is the so-called routing triangle: the client PC sends the initial (SYN) packet to the public address, the Mikrotik dst-nats the packet to the server’s private IP and sends it there, but the source address remains the LAN client’s one so the server’s response goes directly to it, while the client expects it to come from the public one so it ignores it.
One possibility is to add a src-nat rule chain=srcnat action=src-nat src-address=192.168.12.0/24 dst-address=192.168.12.1 to-addresses=192.168.12.254 to make sure that the server will respond to Mikrotik’s own address so the firewall’s connection tracker will be able to “un-src-nat” and then “un-dst-nat” the response prior to forwarding it to the client. This is called hairpin NAT.
Another possibility is to use a static DNS on your Mikrotik, so for the LAN clients the fqdn will resolve to 192.168.12.1 straight away.
Sorry again (same reason), in your case that rule is redundant as everything is always src-nated thanks to the rule
action=masquerade chain=srcnat ..no other conditions…
Leaving aside whether such wide-matching rule is a good idea or not, the reason of your trouble must be different. In fact it’s the policy routing again - you assign the routing-mark PureVPN-PPTP to everything from 192.168.12.0/24 via the VPN “WAN”, but there is no specific route to 192.168.12.1 (or 192.168.12.0/24) with that routing-mark, so the marked packets take the default route with that routing-mark instead. So the fastest way out is
/ip route rule add dst-address=192.168.12.0/24 action=lookup-only-in-table table=main
More details here.
Many thanks!
This solves the problem with one caveat: if i want to access a server using the same port out of my LAN from inside, I can’t and get redirected to 192.168.12.1:PORT. how can i solve this?
and can you tell me whats wrong with having just one masquerade rule? I searched very much and couldn’t find whats the best practice for setting up masquerade.
I had to re-read this several times before understanding the problem The problem is that your dst-nat rules do not check the dst-address, only the dst-port. So add dst-address=your.pppoe.public.ip to them and you’ll be good.
First, the best practice is to use src-nat rather than masquerade where IP of the outgoing interface is static, as masquerade on purpose erases all tracked connections in the firewall when the interface goes down and up again, which maxes out the CPU for a while, but let’s say that’s not a issue in home environment.
Next, with your single LAN subnet, the only issue is that not only connections from your LAN clients get to the server with the IP of the Mikrotik as source but also connections from clients in the internet. So if this doesn’t bother you, you can stay as you are. With more LAN subnets, the same problem would be more annoying.
The problem is that your dst-nat rules do not check the dst-address, only the dst-port. So add dst-address=your.pppoe.public.ip to them and you’ll be good.