Community discussions

MikroTik App
 
tms
just joined
Topic Author
Posts: 16
Joined: Fri Jan 08, 2016 1:21 pm
Location: Siofok, Hungary
Contact:

Subnet to another subnet

Fri Jan 08, 2016 1:52 pm

Hi all,


I am very newbie in Mikrotik - using and learning about 2 months.
But have a problem in a bigger system and I do not know what to do or how to.

There's a really old RB532 with 5.9 RouterOS. There are many options and setups in it - understanding very slowly step by step.
About one week ago there was a need to do a 4th subnet, a VLAN - 192.168.4.x. This is a subnet for two devices, 4.10 and 4.11 and there is a pool (4.100-4.110) for PPTP users. It's done.
There is a Windows Server in the 192.168.1.2, running a database on port 1433-1434 and 2554-2555. The 4.x is totally separated, no DNS, no internet, does not seen any devices from 1.x - but I have to have a contact with that database I mentioned. What to do now? I need a Firewall Rule or NAT Rule?

I hope You understand it, sorry for my poor english.

Thanks in advance,

Tom
 
Sob
Forum Guru
Forum Guru
Posts: 9188
Joined: Mon Apr 20, 2009 9:11 pm

Re: Subnet to another subnet

Fri Jan 08, 2016 3:26 pm

It depends. A firewall filter rule that allows traffic from 192.168.4.x (or just selected devices) to 192.168.1.2 and its database ports is good start. Assuming there are already other rules accepting established and related connections, and devices in both networks know where is the other one (either they have the router as default gateway or have static route), you have good chance that it will be enough.
If it's not enough, it could have various reasons. Some other config on router, firewall on 192.168.1.2 only allowing connection from local 192.168.1.x subnet, etc..
 
tms
just joined
Topic Author
Posts: 16
Joined: Fri Jan 08, 2016 1:21 pm
Location: Siofok, Hungary
Contact:

Re: Subnet to another subnet

Fri Jan 08, 2016 4:41 pm

It depends. A firewall filter rule that allows traffic from 192.168.4.x (or just selected devices) to 192.168.1.2 and its database ports is good start. Assuming there are already other rules accepting established and related connections, and devices in both networks know where is the other one (either they have the router as default gateway or have static route), you have good chance that it will be enough.
Yes, it is enough for me to contact just in 1433-1434 and 2554-2555.
Have to do a forward rule in new connection, established and related?
 
tms
just joined
Topic Author
Posts: 16
Joined: Fri Jan 08, 2016 1:21 pm
Location: Siofok, Hungary
Contact:

Re: Subnet to another subnet

Sat Jan 09, 2016 6:57 pm

It depends. A firewall filter rule that allows traffic from 192.168.4.x (or just selected devices) to 192.168.1.2 and its database ports is good start..
Thanks!

And how a firewall rule looks like?
 
tms
just joined
Topic Author
Posts: 16
Joined: Fri Jan 08, 2016 1:21 pm
Location: Siofok, Hungary
Contact:

Re: Subnet to another subnet

Sun Jan 10, 2016 10:29 am

Thank You!

And how a firewall filter rule looks like? I need a forward chain?
 
tms
just joined
Topic Author
Posts: 16
Joined: Fri Jan 08, 2016 1:21 pm
Location: Siofok, Hungary
Contact:

Re: Subnet to another subnet

Mon Jan 11, 2016 9:49 am

Sorry for multiple posts, I thought I do something wrong my and posts doesn't appear... I'm new in this forum... :)
 
User avatar
ZeroByte
Forum Guru
Forum Guru
Posts: 4047
Joined: Wed May 11, 2011 6:08 pm

Re: Subnet to another subnet

Mon Jan 11, 2016 8:18 pm

When establishing security policies, I prefer to use interface names where possible to allow future flexibility.

In your case, I would use the source interface of the .4.x network (we'll say ether4 in this example, but use your actual interface on your system) and the dst-address=ip.of.db.server as the destination....

/ip firewall filter
add chain=forward action=accept in-interface=ether4 dst-address=192.168.1.2 protocol=tcp dst-port=1433-1434,2554-2555
add chain=forward action=drop in-interface=ether4

These rules would be VERY strict - allowing anything in the ether4 network (whatever its IP range is - you could change it 12 times a day and this rule would not need to be changed to keep working) access to 192.168.1.2 for database, and nothing else.

If you want to allow this network onto the Internet in general, you could either add a rule between the two above:
add chain=forward action=accept in-interface=ether4 out-interface=wan
(use the wan interface name on your system)

or perhaps earlier in your chain you have an all-purpose rule that simply allows out-interface=wan regardless of which interface it came from... this would work as well, and you wouldn't need the third rule.

You may also want to allow icmp from ether4 just so internally, you can ping the rest of your network, and things like udp port unreachable, etc - these sorts of control messages will work properly.
 
tms
just joined
Topic Author
Posts: 16
Joined: Fri Jan 08, 2016 1:21 pm
Location: Siofok, Hungary
Contact:

Re: Subnet to another subnet

Tue Jan 12, 2016 11:32 pm

When establishing security policies, I prefer to use interface names where possible to allow future flexibility.

In your case, I would use the source interface of the .4.x network (we'll say ether4 in this example, but use your actual interface on your system) and the dst-address=ip.of.db.server as the destination....

/ip firewall filter
add chain=forward action=accept in-interface=ether4 dst-address=192.168.1.2 protocol=tcp dst-port=1433-1434,2554-2555
add chain=forward action=drop in-interface=ether4

These rules would be VERY strict - allowing anything in the ether4 network (whatever its IP range is - you could change it 12 times a day and this rule would not need to be changed to keep working) access to 192.168.1.2 for database, and nothing else.

If you want to allow this network onto the Internet in general, you could either add a rule between the two above:
add chain=forward action=accept in-interface=ether4 out-interface=wan
(use the wan interface name on your system)

or perhaps earlier in your chain you have an all-purpose rule that simply allows out-interface=wan regardless of which interface it came from... this would work as well, and you wouldn't need the third rule.

You may also want to allow icmp from ether4 just so internally, you can ping the rest of your network, and things like udp port unreachable, etc - these sorts of control messages will work properly.
Thank you for your reply!

First of all this is a very complex and problematic system in a company. Made many other people I face with the problems right now.
There's an old RB532 with 3 ethernet ports. My 192.168.4.x sits on a VLAN which sits on a bridge. :)
I follow your instructions and do a firewall rule - two rules:

chain=forward action=accept src-address=192.168.4.0/24
dst-address=192.168.1.2 in-interface=vlan4

chain=forward action=accept src-address=192.168.1.2
dst-address=192.168.4.0/24 out-interface=vlan4

First of all I tried without any ports and it worked, I could ping the devices I needed from INSIDE the 4.x network.
But after came the harder things.
There's a PPTP VPN connection with it's own pool (10.20.4.201-210). All connections from this area forwarded to the 4.x network - but I can not ping the 192.168.1.2 and can not reach the database when I log in with VPN connection.

Have to try another method?
 
User avatar
ZeroByte
Forum Guru
Forum Guru
Posts: 4047
Joined: Wed May 11, 2011 6:08 pm

Re: Subnet to another subnet

Wed Jan 13, 2016 12:32 am

[I follow your instructions and do a firewall rule - two rules:

chain=forward action=accept src-address=192.168.4.0/24
dst-address=192.168.1.2 in-interface=vlan4

chain=forward action=accept src-address=192.168.1.2
dst-address=192.168.4.0/24 out-interface=vlan4
You missed my point though - Don't put any IP addresses in the rules when you specify interface names, unless your goal is to also stop IP address spoofing.... and I'd actually use strict RPF checking to block spoofing. (IP / Settings / RP Filter -> Strict)

So remove src-address=192.168.4.0/24 from the first rule.

The second rule shouldn't be necessary if you have this rule early in the forward chain (usually it's the first rule in forward):
chain=forward action=accept connection-state=established,related

As for the VPN clients - make sure you have the state=established,related rule in force on your router.

If you think it's a filtering problem, try a simple rule that says chain=forward action=accept dst-address=192.168.1.2
and put it first in the forward chain - if this doesn't fix it, then the problem's probably not the firewall. Check IP routes on the client side to make sure they're going to use the VPN to reach 192.168.1.0/24
 
tms
just joined
Topic Author
Posts: 16
Joined: Fri Jan 08, 2016 1:21 pm
Location: Siofok, Hungary
Contact:

Re: Subnet to another subnet

Thu Jan 14, 2016 1:25 am

[I follow your instructions and do a firewall rule - two rules:

chain=forward action=accept src-address=192.168.4.0/24
dst-address=192.168.1.2 in-interface=vlan4

chain=forward action=accept src-address=192.168.1.2
dst-address=192.168.4.0/24 out-interface=vlan4
You missed my point though - Don't put any IP addresses in the rules when you specify interface names, unless your goal is to also stop IP address spoofing.... and I'd actually use strict RPF checking to block spoofing. (IP / Settings / RP Filter -> Strict)

So remove src-address=192.168.4.0/24 from the first rule.

The second rule shouldn't be necessary if you have this rule early in the forward chain (usually it's the first rule in forward):
chain=forward action=accept connection-state=established,related

As for the VPN clients - make sure you have the state=established,related rule in force on your router.

If you think it's a filtering problem, try a simple rule that says chain=forward action=accept dst-address=192.168.1.2
and put it first in the forward chain - if this doesn't fix it, then the problem's probably not the firewall. Check IP routes on the client side to make sure they're going to use the VPN to reach 192.168.1.0/24
Thank You for your help!

Tom