Hello,
I have a Raspberry Pi connected to my MikroTik router, I want all the traffic received from clients be routed through this raspberry pi first and after Raspberry Pi forwards the traffic out, it would be routed to Internet router by my Mikrotik router.
Seems easy, But I am not able to make it work.
Here is my network diagram :
What I have done is that I have set the default route of the mikrotik to my Raspberry Pi :
/ip route add distance=50 gateway=192.168.101.1
Then marking all of the packets coming out of Raspberry Pi in Mangle Table and routing them to Internet gateway :
I tried changing NAT to out interface of RPi but still doesnt work. Although it didnt make sense in my opinion.
As I said I have Internet access inside my Raspberry Pi, showing packets coming out of raspberry pi are being marked successfully and routed properly. why dont I have Internet access on clients is a mystery to me.
I tried the Torch and log on rules. They show packets are being marked and routed to Internet gateway, but I cant find where is the culprit. unfortunately I dont have sniffering available on my Internet router so I can not see what exactly is sent out to Internet router. it seems a very easy setup, but cant fix it for 2 days.
Your MikroTik router includes a packet sniffer!
This can do both sniffing to an in-memory buffer and basic display, and to a file which you can examine in wireshark.
Why not just put the Pi between the clients and the Mikrotik? Then you wouldn’t need all of this complicated plumbing in your configuration…
(Mad science is definitely a valid answer, of course)
I can understand why he is doing it this way… a Pi has only a single ethernet interface.
Of course it can be solved using a VLAN switch but then the solution is close to what it is with the router.
Still, it should be possible what he is trying, there is just a mistake somewhere and by tracing the traffic it should
be possible to find it.
I already had IP forwarding enabled on my RPi.
I guess I found the problem, I noticed client packets do not get masqueraded at all before being sent out to Internet, It seems because packets are forwarded once for RPi and received again are not considered NEW and are not traversed through NAT table.
When I masqueraded the packets inside RPi which changes the src IP to RPi IP, the problem was resolved.
Does it make sense ?
The reason wasn’t state but routing. If the Pi doesn’t masquerade then the arc IP of outbound packets is the original host so the replies are being mid-directed.
Can you explain this please ? I still cant understand why it could be a routing problem and packet sniffer showed client packets were being routed to Internet properly but not being source nated.
If the Pi doesn’t do any NAT then the packets follow the orange path - note that as the packet leaves the Pi, the src IP will still be the Client’s IP, and not the Pi’s IP.
When the reply comes back from the Internet, the destination IP will be the Client’s IP, not the Pi’s address. I’m not sure what process is being done by the Pi, but if it needs to be un-done by the Pi on replies in order for things to work, then this scenario would break.
The green path represents the path that packets take when the Pi is doing srcnat on the traffic. I didn’t have room to add the sample packet headers to the green path, but the dst IP will be 192.168.101.1 and the src will be 8.8.8.8, which is what is needed for the Mikrotik to foward them to the Pi.
Thank you for your reply, the path that you have illustrated is absolutely correct if there no NAT on RPi, but at the time I was testing RPi was a simple forwarding router, no process was being done on packets and packet sniffer showed packets are being sent out to Internet without being masqueraded on Mikrotik while I had a working masquerade rule. so the packets were being dropped on next router because their source IP was invalid.
I still believe it had something to do with state of packets in Mikrotik connection tracking since they were routed twice through the same router (MTik->RPi->MTik) and I was expecting it to be NATed at second time which obviously was not performed.
