Community discussions

MikroTik App
 
User avatar
mrakar
just joined
Topic Author
Posts: 16
Joined: Fri Jun 29, 2012 4:33 pm
Contact:

Masqueraed and routing, few questions (multiple LAN, multiple WAN scenario)

Sat Mar 07, 2015 8:04 pm

I have five different private subnets on my LAN. Each of this five networks end up on their respective port on my CCR router). I also have two WAN links; in nature this is one WAN link but there is also VPN (PPTP client) interface over WAN link as well.

Now, each subnet should be isolated from one another (subnets should be unreachable from one another, except for two LAN subnets which should be routable)

Four LAN subnets go out to the internet directly to WAN link. One of LAN subnets should be routed to VPN link.

I have created two NAT masquerade rules (one for all subnets to direct traffic to WAN link; second for subnet which needs to be redirected to VPN). I have created single mangle rule (for route marking VPN traffic based on source IP address), and I have two IP route rules (one 0.0.0.0/0 to WAN link; second 0.0.0.0/0 for marked traffic to VPN interface).

It appears that my subnets which need to contact WAN link work correctly, but my VPN link does not.

My questions are:

1. When I create masquerade NAT; should I make different NAT for each LAN subnet?

I have created one masquerade without selecting subnet IP ranges and selecting outgoing WAN link and this seems to work ok (limiting which subnet sees which subnet is done with filtering)..I also have second masquerade NAT for directing traffic to my VPN link.
I ask this because somewhere in documentation I have read that each subnet should have its own masquerade NAT.

2. When creating masquerade, should I select traffic source based on IP addresses or based on ethernet port?

Somewhere in documentation I read that port based source selection works only with UDP and TCP traffic.


3. If I have five subnets and two WAN links; should I create five mangle mark routing rules and five IP routes for marked traffic or can I get away with only one?

One of the subnets have to go to my VPN connection. I have created sngle mangle mark route rule for VPN traffic and created appropriate IP route (with distance less then my "general" 0.0.0.0/0 rule).
This is the source of my problems because it only appear to work partialy. I have access to the internet, it works (but slowly) and some services simply break down or do not work at all (I noticed that some web sites simply do not load and I could not figure reason why).

What am I doing wrong and what are best practices for setup like mine?
 
zyzelis
Member Candidate
Member Candidate
Posts: 213
Joined: Sun Apr 08, 2012 9:25 pm

Re: Masqueraed and routing, few questions (multiple LAN, multiple WAN scenario)

Sat Mar 07, 2015 9:27 pm

Just drop packets in filter forward chain.
 
User avatar
mrakar
just joined
Topic Author
Posts: 16
Joined: Fri Jun 29, 2012 4:33 pm
Contact:

Re: Masqueraed and routing, few questions (multiple LAN, multiple WAN scenario)

Sun Mar 08, 2015 3:45 pm

Just drop packets in filter forward chain.
Why drop packets and which packets to drop?
I do not understand what this means and how it relates to my questions.
 
User avatar
ZeroByte
Forum Guru
Forum Guru
Posts: 4047
Joined: Wed May 11, 2011 6:08 pm

Re: Masqueraed and routing, few questions (multiple LAN, multiple WAN scenario)

Sun Mar 08, 2015 7:48 pm

NAT table should be the simplest table of all in your router.
In the srcnat chain:
rule 1: out-interface= WAN1, action = masquerade
rule 2: out-interface=WAN2, action = masquerade.
(if the VPN doesn't use a tunnel interface, then you will want to put exceptions (accept action, instead of masquerade) for such traffic before these masquerade rules)

Done with NAT table.

You will never want to use Wan1's IP when forwarding traffic in from WAN2 out LAN3, or any other strange combination. Don't try to use NAT for anything other than keeping the correct IP addresses on the correct interfaces.

Routing policy is done with the mangle table + routing policy.
For each policy you have, create a set of static routes with a routing mark (they're just numbers, so make Lan1 policy = routing mark 1, Lan2 = mark 2, etc.)
Put in routes that follow the policy you want.
Then in mangle table, pre-routing chain in-interface = LAN1 action = set routing mark to 1, etc.

This will give the behavior that you want.
 
User avatar
ZeroByte
Forum Guru
Forum Guru
Posts: 4047
Joined: Wed May 11, 2011 6:08 pm

Re: Masqueraed and routing, few questions (multiple LAN, multiple WAN scenario)

Sun Mar 08, 2015 7:54 pm

Just drop packets in filter forward chain.
Why drop packets and which packets to drop?
I do not understand what this means and how it relates to my questions.
Zyzelis is 100% correct. In my previous response, this is all to build "100% open" connectivity - in other words, NAT and routing policy do not try to limit certain types of access. They simply describe the topology of your network.
If you want to block any LAN<>LAN traffic other than LAN1<>LAN2, then you should stop this with a rule in the filter table / forwarding chain.

Suppose you have a server on LAN1 that you want to protect from users on LAN3, but otherwise, want LAN3/LAN1 to reach each other - you add a forward chain in-interface=LAN3, dst-address=ip.of.server, action=drop

When you have multiple LANs like this, it is a good idea to make your forwarding chain simple with only a few basics like "allow established/related" connections, then a set of jump rules to user-defined chains for each LAN. This way, you are sure that rules you put in "LAN1-policy" chain will not affect users in the other LANs. It also makes your performance more efficient because a packet for LAN3 doesn't need to be checked against every rule for LAN1 - just the rule that would jump into LAN1-policy chain.
 
User avatar
mrakar
just joined
Topic Author
Posts: 16
Joined: Fri Jun 29, 2012 4:33 pm
Contact:

Re: Masqueraed and routing, few questions (multiple LAN, multiple WAN scenario)

Sun Mar 08, 2015 8:23 pm

NAT table should be the simplest table of all in your router.
In the srcnat chain:
rule 1: out-interface= WAN1, action = masquerade
rule 2: out-interface=WAN2, action = masquerade.

Done with NAT table.

You will never want to use Wan1's IP when forwarding traffic in from WAN2 out LAN3, or any other strange combination. Don't try to use NAT for anything other than keeping the correct IP addresses on the correct interfaces.

Routing policy is done with the mangle table + routing policy.
For each policy you have, create a set of static routes with a routing mark (they're just numbers, so make Lan1 policy = routing mark 1, Lan2 = mark 2, etc.)
Put in routes that follow the policy you want.
Then in mangle table, pre-routing chain in-interface = LAN1 action = set routing mark to 1, etc.
Currently, I try to use PPTP for VPN protocol.

Your NAT config does not "discriminate" on source addresses, is that ok?; my rules for NAT are like:

rule 1: out-interface=VPN src-address=192.168.2.0/24 action = masquerade
rule 2: out-interface=WAN action = masquerade

Do I need to use src-address? is the order of NAT rules important?

As for mangle/IP route rules; I need to make mangle for each LAN separately?

I currently have single mangle and route rule which marks and points to VPN, and all others use default route (since all of them go out on same interface) Does it mean something if all other LANs are not marked?

To make things more clear I have following setup (office network, no servers on the inside which needs to be published):

WAN ether12 - link to my ISP
VPN interface - VPN to my VPN provider (goes out over ether12)

LAN1 ether1 - office lan 192.168.1.0/24
LAN2 ether2 - VPN lan 192.168.2.0/24
LAN3 ether3 - media lan 192.168.3.0/24
LAN4 ether4 - spare lan 192.168.4.0/24
LAN5 ether5 - guest WLAN 192.168.5.0/24

LAN1 and LAN2 can/should see each other, LAN3, LAN4, LAN5 should just have internet access (which is throttled via simple queue rule). LAN3, LAN4, LAN5 have simple filters which prohibits them accessing other LANs.

In my current setup; there is one NAT which is used for LAN1, LAN3, LAN4, LAN5.
There is second NAT which is used for VPN interface and it has src-address
There is single mangle rule which marks LAN2 traffic with route mark VPN
There is general 0.0.0.0/0 rule for ether12 (distance 5, no route marks)
There is additional 0.0.0.0/0 rule for VPN interface with route mark VPN (distance 5)

As I wrote before, it appears that everything from LAN1, LAN3, LAN4 and LAN5 works correctly BUT when I try to use my LAN2 and try to access something on the other side of VPN I do have trouble accessing content- It appears to work but also some services break down and are generally not reliable; I see that VPN link has correct address and path to the servers on the other side is accessible, it is just that when the server on the other side starts sending larger amounts if data that it breaks or is not reliable.
My thinking was that maybe, since I use PPTP client for VPN, something breaks with routing through my NAT specially for GRE protocol (I do have pptp helper activated, I also noticed that GRE helper is not avaliable anymore).

Any suggestion is welcome.
 
User avatar
ZeroByte
Forum Guru
Forum Guru
Posts: 4047
Joined: Wed May 11, 2011 6:08 pm

Re: Masqueraed and routing, few questions (multiple LAN, multiple WAN scenario)

Sun Mar 08, 2015 9:12 pm

Currently, I try to use PPTP for VPN protocol.
If memory serves, that creates an interface, correct? If so then that's great. (I would think you would NOT want to use NAT across a VPN - making both sides see each other is the point, right?)
Your NAT config does not "discriminate" on source addresses, is that ok?; my rules for NAT are like:

rule 1: out-interface=VPN src-address=192.168.2.0/24 action = masquerade
rule 2: out-interface=WAN action = masquerade

Do I need to use src-address? is the order of NAT rules important?
It does not discriminate. That is intentional. If a packet goes out WAN1, it is useless on the Internet unless its source IP is the one from that ISP right? Same goes for WAN2. NAT should not decide who is allowed to access / who should use a certain path. It just says "if a packet goes this way, make it useable." - You use other functions to decide who goes that way, and if they are allowed to do so.

And yes, the order of rules is important.
As for mangle/IP route rules; I need to make mangle for each LAN separately?

I currently have single mangle and route rule which marks and points to VPN, and all others use default route (since all of them go out on same interface) Does it mean something if all other LANs are not marked?
You don't have to. Routing marks work like this:
Packets with marks on them will use a route with the same mark before they use a route with no mark. (even if the unmarked route is more specific, has lower distance, etc).
If no marked routes match the destination, then the standard (unmarked) routes are checked.
Marked packets are never forwarded by routes with a different mark than the packet.

So, you can mark packets now and create marked routes later if you need to, but it's not necessary.

Your performance issue you mention could be due to a bandwidth bottleneck. Does the other site have an Internet connection much faster than yours? Your bandwidth could be getting filled by the large data transfers. Try rate-limiting these transfers with another simple queue.

Also - watch the CPU usage on your router while doing the transfers. Crypto could be taking all CPU....
 
User avatar
mrakar
just joined
Topic Author
Posts: 16
Joined: Fri Jun 29, 2012 4:33 pm
Contact:

Re: Masqueraed and routing, few questions (multiple LAN, multiple WAN scenario)

Sun Mar 08, 2015 10:03 pm

to the question on the top; yes, PPTP-client creates interface

Also, all of my LANs use private IP addresses and both WAN and VPN use public addresses so I have to have NAT in between.
Your performance issue you mention could be due to a bandwidth bottleneck. Does the other site have an Internet connection much faster than yours? Your bandwidth could be getting filled by the large data transfers. Try rate-limiting these transfers with another simple queue.

Also - watch the CPU usage on your router while doing the transfers. Crypto could be taking all CPU....
I do not think that CPU is problematic since I use CCR which is rated to waaay much bigger traffic then I have (low mbits), not to mention that PPTP itself do not support complex encryption.

hm, summary of the discussion above is that my setup appear to be correct and yet it does not work reliably (only for the traffic over vpn connection, and as far as I know only for the incoming traffic from VPN to my LAN2).

.I am thinking that maybe something with incoming traffic (I mean with flow of incoming traffic within the router) is not correct and I have to figure how to track this problem down.
 
User avatar
ZeroByte
Forum Guru
Forum Guru
Posts: 4047
Joined: Wed May 11, 2011 6:08 pm

Re: Masqueraed and routing, few questions (multiple LAN, multiple WAN scenario)

Sun Mar 08, 2015 10:29 pm

.I am thinking that maybe something with incoming traffic (I mean with flow of incoming traffic within the router) is not correct and I have to figure how to track this problem down.
One thing to try - try disabling your simple queue entirely, just to see if it makes a difference.
When I was developing a standardized queueing system to use for customer routers, I had many strange behaviors, including slower-than-expected throughput and no queue showing red....
 
User avatar
mrakar
just joined
Topic Author
Posts: 16
Joined: Fri Jun 29, 2012 4:33 pm
Contact:

Re: Masqueraed and routing, few questions (multiple LAN, multiple WAN scenario)

Sun Mar 08, 2015 11:25 pm

One thing to try - try disabling your simple queue entirely, just to see if it makes a difference.
When I was developing a standardized queueing system to use for customer routers, I had many strange behaviors, including slower-than-expected throughput and no queue showing red....
I added queue rule (bandwidth throttling for my wlan guests) in the end, I had problems with my VPN all of the time.

Who is online

Users browsing this forum: JesusUve, xrlls and 97 guests