Yes, if the rule is set up correctly. A destination address of 0.0.0.0 will not work. You either have to let that off (it is not necessary), or you have to make it 0.0.0.0/0
It should not have noticeable delay. Are you accessing it via MAC address or via IP address? If the latter has a thirty second delay something is seriously wrong.
I am still having trouble getting this to work and I cannot find anything on the wiki’s similar enough to what I am trying to accomplish, sorry if I’m being a bother.
What I want to be able to do is
Web request from client behind router A → ipip tunnel (one way tunnel) → Router B → webserver → router A
Since the latest change I am able to see the requests traversing the tunnel and hitting the webserver but they seem to have a return REPLY DST ADDRESS of 192.168.1.111.
Without the mangle rule applied the packets have a Reply DST of my WAN/Public IP 222.154.x.x which is what I would expect
How can I make the packets that traverse the tunnel have a return DST of the WAN IP of the router?
[admin@MikroTik] > ip route print
Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,
B - blackhole, U - unreachable, P - prohibit
I don't have my network diag software on this machine if you need I can get it at the weekend.
I want traffic on port 80 and 443 to be tunneled to another router, then access the webhost (it is working up till here).
The webhost needs to know to send the requested page to the source router (222.154.xxx.15) and the source router needs to recognize and accept this on it's firewall.
Mikrotek 222.154.xxx.15 -> IPIP tunnel 192.168.170.1 for ports 80 and 443 -> Cisco 6500 with tunnel interface 192.168.170.2 and public IP 202.89.xxx.245 -> Webhost -> 222.154.xxx.15
The router can’t send a packet with source IP A to destination IP B and then receive a packet to destination IP B but from source IP C as a reply. If reply traffic is sent to public IP of router and doesn’t travel back via the tunnel the router cannot know what internal LAN IP address to forward the traffic to because there is no NAT action to undo.
I guess you could try source NATing the packet through the tunnel to the router WAN IP via an action of src-nat and a specific to-address (at which point you will lose the internal source IP as seen by the other end - which makes an IPIP tunnel pointless), but I am pretty sure connection tracking takes interfaces into account and will discard the return traffic as coming in from the wrong interface (WAN vs tunnel) anyway.
I don’t think what you’re trying to do can be done. Why do you want a one way tunnel?
If you’re doing NAT across the tunnel, how is it a one way tunnel? NAT implies that the source address arriving at the other endpoint is the IP address of the tunnel interface. In your case that is a private IP address, so reply traffic has to go across the tunnel or the destination would be unreachable.
My job is 90% Cisco. Maybe if you post a Cisco to Cisco configuration I can help out. I don’t do contract work so I cannot guarantee I will reply in a timely manner.
That performs the same kind of NAT your Cisco routers are doing. However, I’m not at all sure this is going to work on RouterOS. Give it a try - maybe it does. You’re already sending the traffic across the IPIP tunnel, and that NAT rule above will perform the same source NAT translation you’re doing on Cisco so you’ll have that side completely duplicated.
I think it’s likely that while the Cisco NAT stack can apparently process the return traffic the RouterOS NAT stack might not be able to piece together that the return traffic is part of the flow - it’s my impression that connection tracking (which is responsible for assigning packets to flows, which in turn influences how source NAT is undone for return traffic to forward the packet back to the private IP address that originally initiated the flow) also uses input and output interfaces in its decision making process. Since the input interface for return traffic won’t match the output interface the original packet left through return traffic might be discarded due to not being able to match it to a flow. However, I might be completely and utterly wrong on that so it’s worth trying. If it doesn’t work I don’t see how you can implement your Cisco solution on RouterOS simply because the NAT stacks have slightly different functionality.