In bridge mode
Port 1 = Internet
Port 2 = management network (172.16.0.0/16)
Port 3 = Client A (192.168.1.0/24)
Port 4 = Client B (192.168.2.0/24)
It’s important that I can access the client networks from the management network.
Turns out that it’s also important that the client networks give out DHCP addresses from the range of the client networks (for example, 192.168.1.50-200)
Reading the documentation, it doesn’t appear that operating in bridge mode you can give out these DHCP pools due to their slave status. I’m hoping that it’s just a case of not being able to successfully interpret what I’m reading. Advice will be much appreciated.
Well, this would explain why we didn’t do a bridged system in the first place. (sorry, had a couple of strokes between the initial setup of the router and recently modifying the router to solve a problem that appeared following a firmware update so my brain’s a little scrambled…)
So, here’s where I am if I restore the backup:
All interfaces work fine in router mode. However, after the FW update I can no longer reach devices from the management interface to one of the other interfaces. This was initially implemented so that I could perform off-site backups from, say, the 192.168.1.x network to the 172.16.x.x network. It worked for several years. Today, I can’t ping devices on the 192.168.1.x network, remote into them, or pull backups, from my management network.
I’m tempted to revert to the mostly working configuration so that everyone’s getting proper DHCP from their ranges, then turn off all the firewall rules to determine whether this is a FW issue or something else.
You’re trying to upgrade from which to which version? If version difference is minor, then what you’re seeing might be due to some bug. If the difference between original and new ROS version (e.g. upgrade from v6 to v7), then it could be incompatibility of your particular configuration.
You might want to post full configuration of your device as output from command /export file=anynameyouwish (add option hide-sensitive if ROS version is 6.x) executed in CLI … fetch file to management computer, open it with your favourite text editor and redact remaining sensitive data, such as PSK, serial number and public IP address.
The firmware prior to the upgrade was 6.x and it currently reads that it is tilegx, factory firmware 3.09, current firmware 7.18, upgrade firmware 7.18
Attached, please find the current.rsc dump.
I’m not sure if this is the source of the problem, but I attempted to create a FW rule to allow the 172.16 network to communicate with the 192.168.1 network (It hasn’t helped) so the question is whether the entry is in the correct form and whether it is in the right location in the chain.
PS: I’m starting to consider setting aside a sub of the 172.16 network (maybe 172.16.250.x/24) with a DHCP Pool in that range, then reconfigure everything on the 192.1168.1.x/24 network and adopt them to my mgt network to solve this problem. Obviously, this is not a great solution from a security standpoint but it may be necessary.
This means that connections from management subnet to “Berglund” (192.168.1.0x/24) should work: the initial forward connection is accepted by the third rule, all the rest of packets are accepted by first two rules.
However you don’t have a similar rule for “Drake” (192.168.2.0/24).
While looking into configuration I spotted a few minor things:
/ip dhcp-server
add add-arp=yes address-pool=*4 always-broadcast=yes interface=ether2-Unused lease-time=10m name=TEST
It refers to non-existing address pool. Yes, it’s bound to disabled interface, but none the less
/ip/firewall/filter
it’s recommended to group rules according to chain … only rule order within same chain matter. Interleaved rules for different chains make reading configuration much harder
/ip/firewall/filter
add action=accept chain=forward comment=
“forward - eth1 - established - accept” connection-state=established
in-interface=ether1-gateway
This rule is never hit … because the “established” rule 3 lines higher will match also packets which would trigger this rule.
/ip/firewall/filter
add chain=input comment=“Accept Established / Related Input”
connection-state=established,related
Again, this rule is never hit … because two rules above it will match same packets
/ip/firewall/filter
add action=fasttrack-connection chain=forward comment=
“Fast Track Established / Related Forward” connection-state=
established,related hw-offload=yes
This rule (again) won’t match too many packets … because of accept established and accept related rules higher in the chain.
/ip firewall connection tracking
set udp-timeout=10s
This setting is pretty short. If there’s an ongoing UDP “connection” between management and Berglund … and there’s a pause in traffic for longer than 10s, then connection will get removed from connection tracking list. And if the next packet should flow from Berglund towards management, it’ll get dropped … because to connection tracking machinery that would seem as new connection in direction not allowed by any filter rule.
But all in all, I don’t see anything which would cause a drastic difference in how router works simply due to upgrade from v6 to v7.
So, I made all the changes listed, including increasing udp timeout to 1 minute. However, I still can’t hit anything from the mgt network to the Berglund network.
I’m going to attempt one more change to see if the problem disappears when I try via another computer that’s connected directly via 1gbps instead of the 10gbps switch. Who knows.
Just tested and that didn’t work. tracert stops at the router and never finds a path to 192.168.1.x
I guess the only option is to transfer them to my internal network in order to restore the connection - I don’t see another option. Last thoughts?