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
Can we see the configuration?
Mangle, ip address, ip route
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
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
\
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
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?
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
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/
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.
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).
chain=prerouting action=mark-connection new-connection-mark= connection mark you want to use passthrough=yes in-interface=interface you expect the connection on
chain=prerouting action=mark-packet new-packet-mark=packet mark you want to use passthrough=yes in-interface=interface
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/