Community discussions

MikroTik App
 
glucz
Member Candidate
Member Candidate
Topic Author
Posts: 123
Joined: Wed Jun 06, 2007 10:25 pm

Why does preferred source not work in routing for Routeros 3

Sun Feb 17, 2008 4:47 pm

I used to have a system where I had different groups of users masqerading on different public IP addresses. I was routing them to the proper IP using simple routing with routing marks and rules with preferred sources. In 3.x now everyone sees the outside world on the same IP, which is the base router IP. Does anyone know if this is a feature or a bug?

I saw someone else mention this as a bug ... but I didn't find any usable solution or suggestion to this.

Thank you
Geza
 
User avatar
macgaiver
Forum Guru
Forum Guru
Posts: 1764
Joined: Wed May 18, 2005 5:57 pm
Location: Sol III, Sol system, Sector 001, Alpha Quadrant

Re: Why does preferred source not work in routing for Routeros 3

Mon Feb 18, 2008 9:54 am

Can we see the configuration?

Mangle, ip address, ip route
 
glucz
Member Candidate
Member Candidate
Topic Author
Posts: 123
Joined: Wed Jun 06, 2007 10:25 pm

Re: Why does preferred source not work in routing for Routeros 3

Mon Feb 18, 2008 5:29 pm

What I have here is PPTP and L2TP users from different locations. Some are single computers, some are complete networks. A specific group of these connections get their routing marked as EV2

I was masquerading the connections to 193.239.149.97 via 87.229.53.253. Note that the base IP of the router is 87.229.53.254 (Please see red IP)

I was achieving this via a route rule #7 (please see red ROUTE) setting the source to 87.229.53.253. I have a corresponding NAT rule #2 (please see red NAT) and a MANGLE rule to handle the backward data flow #4 (please see red MANGLE)

This worked perfectly with routeros 2.9, but it doesn't work in 3.0 . As I experienced the preferred source doesn't work for ROUTE, so the packages were sent via 87.229.53.254 . I had to modify all rules accordingly .. but this is not what I need. I need to send these packages via 87.229.53.253.



This is the configuration:

IP ADDRESSES

Flags: X - disabled, I - invalid, D - dynamic
# ADDRESS NETWORK BROADCAST INTERFACE
0 87.229.53.254/24 87.229.53.0 87.229.53.255 ether2
1 87.229.53.250/32 87.229.53.0 87.229.53.255 ether2
2 87.229.53.252/32 87.229.53.0 87.229.53.255 ether2
3 87.229.53.253/32 87.229.53.0 87.229.53.255 ether2

4 D 87.229.53.254/32 87.229.53.251 0.0.0.0 pptp-ev2mail
5 D 10.99.99.3/32 10.99.99.4 0.0.0.0 pptp-glucz-router
6 D 10.99.99.1/32 10.99.99.2 0.0.0.0 pptp-ev2-ronaut
[admin@EV2 - EPIA] >

As you can see there are some pptp users logged in.


MANGLE


0 chain=prerouting action=mark-routing new-routing-mark=ev2 passthrough=yes
dst-address=87.229.53.252 dst-port=90 protocol=tcp

1 chain=prerouting action=mark-routing new-routing-mark=ev2 passthrough=yes
dst-address=87.229.53.252 dst-port=7656 protocol=tcp

2 chain=prerouting action=mark-routing new-routing-mark=ev2 passthrough=no
in-interface=pptp-ev2-ronaut

3 chain=prerouting action=mark-routing new-routing-mark=ev2 passthrough=no
in-interface=pptp-glucz-router

4 chain=prerouting action=mark-routing new-routing-mark=ev2 passthrough=no
src-address=193.239.149.97 dst-address=87.229.53.253 in-interface=ether2


5 I chain=prerouting action=mark-routing new-routing-mark=luczkft passthrough=no
in-interface=pptp-ev2-GLroutolt

6 I chain=prerouting action=mark-routing new-routing-mark=luczkft passthrough=no
in-interface=l2tp-ev2-GLmasquerade

7 chain=prerouting action=mark-packet new-packet-mark=fromoutside passthrough=yes
in-interface=ether2

8 I chain=prerouting action=mark-routing new-routing-mark=luczkft passthrough=no
in-interface=l2tp-luczkft

9 I chain=prerouting action=mark-connection new-connection-mark=help passthrough=no
in-interface=l2tp-help-1





ROUTES


# DST-ADDRESS PREF-SRC GATEWAY-STATE GATEWAY DISTANCE INTERFACE
0 A S 0.0.0.0/0 reachable 87.229.53.1 1 ether2
1 ADC 10.99.99.2/32 10.99.99.1 0 pptp-ev2-ronaut
2 ADC 10.99.99.4/32 10.99.99.3 0 pptp-glucz-router
3 ADC 87.229.53.0/24 87.229.53.254 0 ether2
4 ADC 87.229.53.251/32 87.229.53.254 0 pptp-ev2mail
5 A S 192.168.1.0/24 reachable 10.99.99.2 1 pptp-ev2-ronaut
6 A S 192.168.2.0/24 reachable 10.99.99.4 1 pptp-glucz-router
7 A S 193.239.149.97/32 87.229.53.253 reachable 87.229.53.1 1 ether2





NAT

0 chain=dstnat action=dst-nat to-addresses=192.168.1.75 to-ports=7656 dst-address=87.229.53.252 dst-port=8976 protocol=tcp

1 chain=dstnat action=dst-nat to-addresses=192.168.1.169 to-ports=90 dst-address=87.229.53.252 dst-port=80 protocol=tcp

2 ;;; EV2 masquerade
chain=srcnat action=masquerade routing-mark=ev2 connection-mark=!fixip


3 X ;;; Help accountok internet elerese
chain=srcnat action=masquerade connection-mark=help
 
User avatar
airstream
Member Candidate
Member Candidate
Posts: 188
Joined: Fri Feb 03, 2006 6:33 am
Location: New Zealand

Re: Why does preferred source not work in routing for Routeros 3

Wed Mar 26, 2008 6:59 am

OK, Ive also hit this with Mangle

In 2.9.51 you could have:
chain=forward action=mark-routing new-routing-mark=Even passthrough=no out-interface=WAN2 dst-address=0.0.0.0/0
in 3.6
[admin@MTKROUTER] /ip firewall mangle> add chain=forward action=mark-routing new-routing-mark=Even passthrough=no out-interface=WAN2 dst-address=0.0.0.0/0
failure: routing-mark allowed only in output and prerouting chains
[admin@MTKROUTER] /ip firewall mangle>
Is this a bug?
 
EgyCom
Member Candidate
Member Candidate
Posts: 123
Joined: Thu May 31, 2007 9:47 pm

Re: Why does preferred source not work in routing for Routeros 3

Tue Apr 01, 2008 1:59 pm

we have same problem since upgrade from 2.9.X to 3.4

all configuration is the same but Pref. Source is not running

any one else have this problem
 
galaxynet
Long time Member
Long time Member
Posts: 646
Joined: Fri Dec 17, 2004 2:52 pm
Contact:

Re: Why does preferred source not work in routing for Routeros 3

Wed Apr 02, 2008 2:59 pm

glucz -
2 ;;; EV2 masquerade
chain=srcnat action=masquerade routing-mark=ev2 connection-mark=!fixip
Why not just use src-nat, i.e.,
2 ;;; EV2 scr-nat
chain=srcnat action=src-nat to-address=87.229.53.253 routing-mark=ev2 connection-mark=!fixip

I had tried that masquerade setup you used in 2.9.xx, and depending on the version of ROS it worked and it didn't work... Src-natting was the only way to make sure I got the src IP I wanted....

R/
 
User avatar
airstream
Member Candidate
Member Candidate
Posts: 188
Joined: Fri Feb 03, 2006 6:33 am
Location: New Zealand

Re: Why does preferred source not work in routing for Routeros 3

Thu Apr 03, 2008 12:03 am

OK, this is really starting to become an issue, the workaround I have is:
 3   ;;; Needed For Wan2
     chain=prerouting action=mark-connection new-connection-mark=Even 
     passthrough=yes in-interface=ether2 - WAN2 

 4   chain=output action=mark-routing new-routing-mark=Even passthrough=no 
     connection-mark=Even 
But this is not ideal. It will not catch all UDP streams and mark their routes, or server to client outbound traffic as it is only matching an incoming connections, not outgoing. Basically this only enables a ping reply from the internet to wan2

It gets Better - Interface matching is only allowed in the "prerouting" and "output" chains, so if you try "forward" etc you get routing mark only allowed in .....

The only way we can match out interface/mark route (the only way the routeros will accecpt it) is
 chain=output action=mark-routing new-routing-mark=Even passthrough=no 
     out-interface=ether2 - WAN2
but this mangle rule doesn't even catch anything!

Im now pulling my hair out. We really need forward/interface/mark route. SIP wont work over our WAN2 until this is resolved.

Can we please have the ability to add a routing mark to the forward chain matching the outgoing interface. like in 2.9.51
chain=forward action=mark-routing new-routing-mark=Even passthrough=no out-interface=WAN2 dst-address=0.0.0.0/0
As already mentioned the purpose of said rule enables all traffic bound to go out WAN2 to have the correct routing mark applied. Fairly important.
 
galaxynet
Long time Member
Long time Member
Posts: 646
Joined: Fri Dec 17, 2004 2:52 pm
Contact:

Re: Why does preferred source not work in routing for Routeros 3

Thu Apr 03, 2008 2:50 pm

airstream -

Ok we need to get the rules straight. Input and Output rules only apply to traffic generated or targeted at the ROS box itself - not the traffic going through it.

To match client to Internet connections you'll need three mangle rules; (Basically inside to outside through the router).

1) chain=prerouting action=mark-connection new-connection-mark= connection mark you want to use passthrough=yes in-interface=interface you expect the connection on

2) chain=prerouting action=mark-packet new-packet-mark=packet mark you want to use passthrough=yes in-interface=interface

3) chain=prerouting action=mark-routing new-routing-mark=routing mark you want to use passthrough=no packet-mark=packet mark you used in 2 above

Now nat....
chain=srcnat action=src-nat to-addresses=ADDRESS to-ports=0-65535 routing-mark=Routing mark from mangle (3) out-interface=Interface out (you could leave the 'out interface' off if you use src-nat instead of masquerade, I would try and use the below as well)


You can also use routing rules to help...

/ip route rule....
routing-mark=Routing mark from mangle 3) action=lookup table=New routing table name

/ip route (I can not seem to make this under the terminal window....so use winbox)
/IP Route, select the new routing table name you just made above under /ip route rule.
Your destination 0.0.0.0/0, gateway IP, gateway interface (the one you want), I use the 'check gateway' feature - I use ping, Routing Mark (from mangle above), and insert your preferred source address.


This should do the trick....

There is also a protocol helper just for SIP that you can use under mangle, it is under connection type....


Although re-reading your above post it also looks like you are trying to match connections from the Internet to local servers and send them back out a particular interface/ip combination.... That is really not possible (under any ROS) as you don't control what Interface data packets come in on.... (This is the case in multi-gateway schemes) As long as connection tracking is on - packets answering the request should go back out the correct (same) interface they came in on.... You can make sure by marking connections and packets coming in that interface and appropriately scr-nating the replies....

R/

Who is online

Users browsing this forum: Bing [Bot], kormenator, simtj and 164 guests