Network 1: 192.168.178.0/24, this network has it’s own DHCP server.
Network 2: 10.100.10.0/24, this network has it’s own DHCP server.
These 2 networks are seperated from eachother.
I have a device on the 10.100.10.0/24 network: 10.100.10.210 which has a HTTP server running on port 80. On the other network (192.168.178.0/24) there are multiple devices. I would like the devices on the 192.168.178.0/24 network to be able to connect to the HTTP server that’s running on the 10.100.10.210 device.
I have tried the following:
Connected port 5 of the hEX lite to network 1 (192.168.178.0/24) and I have configured this interface as DHCP client, it receives the following IP: 192.168.178.121.
Connected port 4 of the hEX lite to network 2 (10.100.10.0/24) and I have configured this interface as DHCP client, it receives the following IP: 10.100.10.20.
When I connect my computer to 192.168.178.1/24 and try to visit 192.168.178.121 in my browser I am not able to connect to the HTTP server. The goal is to forward the HTTP request that is send to 192.168.178.121 (hEX lite) to the 10.100.10.20 device. I think this is the same type of configuration as port forwarding with the WAN interface but I want to use the 2 LAN ports.
I hope this makes sense, if there other methods of doing this please let me know.
I would need to see the complete config to ensure accuracy but the only thing required is a firewall forward chain rule. add action=accept chain=forward dst-address=SERVERip dst-port=XXXXX protocol=yyy source-address=list=ServerUsers /ip firewall address-list
add address=IP1 list=ServerUsers
add address=IP2 list=ServerUsers
add address=IP3 list=ServerUsers
etc…
Your setup makes no sense to me. Are you sure that you are getting WAN from the two networks??
Makes me think, the hex is simply a switch and not a router, or the config is completely nonsensical… ?>??
With what I see here, for me, only 1/2 of the story is shown.
The route (default gateway etc) from 10.100.10.210 for 192.168.178.xxx must point to gateway 10.100.10.20, as no src-nat or masquerade is used , 10.100.10.210 will get a request from source 192.168.178.xxx, and must know where to send the answer.
Srcnat and masquerade are normally executed on interfaces in the WAN interface list, when the default firewall is used. But ether4 and ether5 are not a member of the LAN or WAN interface list, so are not handled properly by the default firewall.
Something like ether4 member of the WAN interface list, ether5 member of the LAN interface list, or just use modified FW rules.
[admin@RouterOS] > /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
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 ADS 0.0.0.0/0 10.100.10.1 1
1 DS 0.0.0.0/0 192.168.178.1 1
2 ADC 192.168.178/24 192.168.178.121 ether5 0
3 ADC 192.168.88.0/24 192.168.88.1 bridge 0
4 ADC 10.100.10.0/24 10.100.10.20 ether4 0
Maybe my choice of interface configuration is wrong, let me try to describe the problem again. When devices of the 192.168.178.0/24 network access port 80 on ip 192.168.178.121 then these requests should be forwarded to port 80 on 10.100.10.210. This way the devices on 192.168.178.0/24 can only access port 80 of a single device (192.168.178.121) in the 10.100.10.0/24 network.
You appear to be using the hEX to connect two networks each of which has existing gateways. Whilst the dst-nat rule will forward packets for any TCP port 80 packets arriving on ether5 to 10.100.10.210 those packets will still have a 192.168.178.x source address, and as 10.100.10.210 knows nothing of these addresses it will send replies via its default gateway.
If you apply src-nat in addition to dst-nat the original packets will appear to originate from 10.100.10.20 instead of 192.168.178.x
/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether4
Alternatively if you can assign static addresses on the hEX interfaces to both networks and add static routes to both of the existing gateways that would allow communication between any hosts on the two networks.
And how does the 10.100.10.210 know where to send the answer for 192.168.178.x ? Is 10.100.10.20 it’s default gateway ? What is set in the 10.100.10.0/24 DHCP server as default gateway for these leases.
WIthout srcnat/masquerade activated the return path must be checked for correct route settings.
The 10.100.10.210 device did indeed not know where to send the replies, adding the masquarade rule fixed this problem. Thanks a lot for helping everyone. Devices on the 192.168.178.0/24 network can now open 192.168.178.121 in their browser and connect to the webserver.
It didn’t that was the problem. The 10.100.10.210 was using the default gateway (10.100.10.1) of the 10.100.10.0/24 network. 10.100.10.1 does not know about the 192.168.178.x network, with the masquarade rule the hEX will forward it correctly to the 192.168.178.0/24 network.
