ChrisC

Have you checked in exchange admin center > mail flow > connectors? It could be that the exponential IP is listed in one of the connectors.

It looks like Paddy's tried to talk to the IP listed above (assuming this is your side as you mention the receive errors). Any legacy connectors (potentially that IP) in your exchange online setup that might be getting selected?

Are you (or they) using any upstream email protection like Barracuda etc? Is their email exchange online/Gmail or something on-prem/more custom? It sounds like a connector/gateway misconfiguration on one of the ends. To continue Tom's thinking, have you had a look at their MX record as well to see if there's anything obviously funky? If you're both running exchange online, you wouldn't expect to see raw IPv4 as the server endpoint unless there's some custom routing going on.

Are all your subnets (or a large range to capture them all) configured in the smoothwall under network > routing > subnets? https://kb.smoothwall.com/hc/en-us/articles/15301663008668-Route-traffic-to-downstream-Subnets Generally that with a static route as you have on your core should route everything correctly. You shouldn't need to have all the VLANs configured under the interfaces.

As you've identified an unknown IP, it could be using the local timestamp at the client end, which could be someone in a different time zone. What are the regional settings on your devices?

My immediate thoughts were an inspect element prank. But if that 10.30.192.12 IP address is not part of your network are you looking at a compromise of the office account? Have you got MFA configured (if it's available)? Is there any chance office is used on other systems with the same password that could have had a compromise elsewhere? If it's pointing to not being an internal prank, you need to start working on the assumption of a security incident with a bad actor having access to your systems potentially both internally and externally. Sending a communication to staff outlining that it will be investigated as such and asking for any information might flush out someone trying to have a laugh and be a good opportunity to de-escalate the situation. In the meantime, check out the office managers PC for any apps that you don't manage/recognise and get them to change their passwords as a belt and braces first steps.

So the switch as the core is where all your internal traffic is hitting, the static route is telling everything to use the smoothwall IP as the next hop to get out to the internet. I'm guessing your core switch config in the CLI will have a line that just says "routing" or "IP routing". So that's the routing device for anything internal, then the smoothwall is the routing device for that (using the 0.0.0.0 static route).

Or is 10.100.100.x an internet stub VLAN with it's own range and only untagged on the interface into the core?

I've just reread your middle bit. Looks like VLAN 10 is a huge subnet. The static route on the core is what's telling all external traffic to go via 10.100.100.2.

"There's one IP route on the switch - ip route 0.0.0.0 0.0.0.0 10.100.100.2" That's your static route, so I'm guessing routing is enabled on the core switch (as it's acting as the gateway on your internal ranges) then that static route acts as the gateway address for the core to route internet traffic. What is the subnet mask on VLAN10? Either it's massive and also includes 10.13.xx.xx, or it could be related to some legacy setup (physical guest segregation or something) that doesn't exist anymore. Also going to assume there's an external interface that does to off to ISP equipment if it's a simple setup.

If one end is configured as an lacp trunk, the other end needs to be as well, otherwise they won't play nicely (even if it's a single link)

Have you checked any sort of misconfiguration like having link aggregation/lacp trunk configured that it's not part of, or it creating a loop and STP taking it down? Have you checked the config on the other end matches exactly on the uplink?

I can't find the smoothwall article anymore, it might not be a thing anymore. From my documentation, these are the rules we put in. URLS [yourdomain].hostedrmm.com connectwise.com myconnectwise.net screenconnect.com Firewall [yourdomain].hostedrmm.com - UDP 75 mediator.labtechsoftware.com - TCP and UDP 8002 [yourdomain].hostedrmm.com - UDP 42000-42009 [yourdomain].hostedrmm.com - TCP & UDP 8040 and 8041

Give smoothwall support a shout, there are some rules that need to be added in the back end to stop you getting "too many redirects" or connectivity issues using RMM or ScreenConnect. Depending on your setup you'll also need to allow (and/or not inspect) the web traffic and firewall ports to connectwise. I'll try and dig them up in a bit.

The other thing to check is to make sure the send and receive are correct on either end (you might need to swap the pair over on one of the patch leads.