Arkwright Community Legend ✭✭✭✭✭
Reactions
Comments
-
Just for the benefit of others reading this, what was the fix?
-
Do you have a mixture of "normal" site-site and tunnel-mode [ie, route-based] IPsec tunnels?
-
Check this thread, I think you're asking for the same thing:
-
It's not the routing then - route 14 covers traffic from your problem zones to the internet. However, I just looked at your access rules again. The one you underlined, rule 1. What do you think that's going to do? I think that rule will only allow access from Multimedia zone to the networks that the firewall's WAN…
-
If you haven't done anything specific to route Teams traffic across the VPN then either: a) Teams traffic is not traversing the VPN and your issue with Teams is unrelated to the VPN b) You've created a VPN tunnel with a destination of Any, and all internet traffic traverses the VPN tunnel and goes out to the internet at…
-
The destination isn't going to be translated right, only the source? If you do a packet monitor and filter on the source IP of a thing and want to know what IP the source is being NATed from then you won't see it because you filtered on the known source IP of the thing. The post-NAT packets appear as duplicated packets…
-
"Packet dropped - Policy drop" is the most annoying error, it can be caused by NAT policies, access policies and I think route policies, but never tells you which one. As you've checked the first two, is there a matching route policy for this traffic?
-
The route statements on the switch don't make any sense, why would you have a route to a network that the switch already has an IP in, via something else also in the same network? You need to decide what is doing the routing, the firewall or the switch. If both devices have IPs in all networks then you will end up with…
-
Are you really routing Teams traffic across your site-site VPN? Randomly working-and-not-working isn't usually a sign of a misconfiguration.
-
Rules are processed top-down, first match wins. Create your rule to allow the one thing you want to allow, and below that, create your rule to block everything [or, un-tick the default rule that was created by the VPN policy]. You need to create your rules in the appropriate Zone -> Zone pairing.
-
If the secondary market value of Sonicwall hardware is degraded by Sonicwall no longer transferring without explicit permission of the previous owner, then looking at other vendors is a rational response. Assuming not every other vendor behaves the same way. This is a change in behaviour by Sonicwall, it definitely just…
-
You've specified the source port. Are you sure you meant to do that? It's unusual to have a fixed source port, they're usually randomly generated.
-
What was the resolution? ----- Sorry, ignore this, posts out of order.
-
Sorry, I misread your post as saying that your PoE switch does not have a scheduled reboot function, when in fact you meant that you don't have them on a PoE switch at all. You probably need to raise this with Sonicwall support, it's unlikely that stopping working after less than two weeks is a config issue,
-
As "TCP connection reject received" is logged on the Site A Sonicwall, that suggests it's 192.168.0.253 which is rejecting this, rather than the Sonicwall itself. A packet capture on Site A Sonicwall should confirm this.