I have this network:
S = server on the internet
W = Work router
H = Home router
For security reasons, we allow SSH traffic to our servers only form W router.
So I have VPN between H and W and on H router I have special route, to route all traffic from H to S via W (via VPN).
It works very well, but there is one problem:
For monitoring reasons, I need to ping from S to H.
Ping doesn’t work, coz ICMP ping packet is not routed back to S: due to a specific route, it’s routed back via W (VPN).
My idea is some setup, where I can modify route only for specific traffic, like: when ICMP ping packed is from S, then not route it via W but send in back directly via default gateway.
I tried to play with Firewall, Mangle, Routes… but without success.
Any clue how to solve this?
And, to be more specific, my idea - not sure if right - is:
Mark incomming ICMP packed by route-mark
Add a new route for marked packets to send via WAN (not VPN)
Coz it’s ping, I’m not sure if I need to mark incomming packets, or outgoing packets and if the incomming and outgoing packed is the same, or if those are two packes, and if I mark incomming ICMP packed, if it’s this routing mark preserved in returning - outgoing - packet
I think I understand what you are trying to do, but without seeing all the necessary info, it makes it difficult to make suggestions, i.e. what these special and specific routes looks like?
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
1 ADS 0.0.0.0/0 my-home-isp-gateway 1
3 A S ;;; Office network
10.1.1.0/24 l2tp-out-office 1
4 ADC 10.1.2.0/24 10.1.2.1 bridge 0
11 ADC 10.1.99.1/32 10.1.99.2 l2tp-out-office 0
28 A S ;;; production server via VPN
1.2.3.4 l2tp-out-office 1
This is my working config on the home router.
So I’m routing traffic to prodcution server 1.2.3.4 not via default gateway, but via VPN to office network.
It works well, but when I ping from 1.2.3.4 via WAN (not thru VPN) it fail, coz the ICMP packed is received on Mikrotik, but then routed not to WAN back, but via the VPN
Difficult to follow you and think there is a language barrier, in short (As there can be NATing, etc involved here) I suspect the following is happening:
You ping server 1.2.3.4 (Private IP) from home it works, reason is you have VPN to office with a route to route all traffic to this subnet via L2TP VPN
You try to ping device at home on Private IP from server 1.2.3.4 (Private IP) but does not work, I suspect the reason is that you do not have a route on office router back to your home subnet, so the packet is going out via the WAN / Internet instead of VPN and internet does not know what to do with Private IP’s, so drops the packet
Normally, the solution is connection marking. What you need to do is to choose an outgoing route for an (icmp ping) response depending on the in-interface of the (icmp ping) request it responds to.
A connection mark is assigned to all packets of a connection, regardless the direction.
provides a route for route-marked packets via the normal WAN gateway regardless their destination address.
It is actually possible do it in a simpler way, just route-mark icmp ping response (and no other) packets towards
dst-address=S.S.S.S
with
new-routing-mark=bypass-vpn
, but you still need the last two steps, the specific route for the routing mark and the marking rule in
chain=output
of
/ip firewall mangle
, and it will only work until the IP address of the server changes. Use of connection-mark makes sure that what came in via WAN will be responded via WAN and what came in via the tunnel will be responded via the tunnel regardless particular IP addresses.
PS: only after CZFan has mentioned the language barrier I’ve realized there is none in my case and that the OP’s nickname has a very special meaning
but the trouble was, that there is another route, lower in the routing table:
28 A S ;;;Traffic to server via VPN
server-ip-address/32 l2tp-out 1
The trouble is (what I know), that this specific rote have a priority before 0.0.0.0/.0 route, so I modified the rout for returning ICMP packets to this:
And thanx also to CZFan, sure, wan can speak Czech, but unfortunatelly, it’s (still) not the Word’s default language, bit it will come one day!
Thanx guys!!!
Not exactly true. I know you’ve already found yourself that the reason why it didn’t work as expected was different, but just to clarify: the route with the longest ****
dst-address
prefix is always chosen among all matching routes, that’s true, but only within the same routing table (routing mark, it is almost the same).
Wow, it’s finally working. The trouble was, that in an route for outgoing marked packed I used for gateway interface name (doesn’t work) instead of inerface’s ip address (which works).
Again, there is more to it. In RouterOS, you can only use interface names as routes’ gateways in case of point-to-point interfaces such as tunnels, because the implicit “address” of the gateway is simply “the other end of the tunnel”. For point-to-multipoint (bus-like) interfaces such as Ethernet, you have to configure an address of a particular device on the bus which can handle the packets as a gateway.
On other systems, interface name can be indicated as a gateway even on point-to-multipoint connections, thanks to an icmp router solicitation mechanism. All devices with routing capabilities advertise the fact that they are routers using an icmp broadcast message every other while, and when a device with interface name configured as a gateway needs to route a packet outside the subnet via that interface, it sends it to any of these routers. The router then routes the packet and if its outgoing interface for that packet is the same like the incoming one, it forwards the packet anyway but it also informs the sender that next time it should send it directly to that other device. And the sender is supposed to cache this instruction and follow it the next time it sends a packet to the same destination.
