While there is no formal "connection" with UDP there is still a convention that clients send requests and expect to get responses back with the source IP and port swapped with the Destinatoin IP and port.
Stateful firewalls and NATs therefore assume that packets with a given combination of source IP/source port/Destination IP/Destination port and the ...
Your firewall is maintaining a connection table for UDP connections. For example, when you send a DNS query, the firewall creates an entry for that flow so that the DNS reply will be allowed back into your network. The entries in the table time out after 30 seconds of no activity.
If you have a managed switch that supports VLANs, just separate the WAN and LAN ports onto separate VLANs and you're good. I would not recommend using one switch with all traffic on the same L2 broadcast domain - it causes multiple headaches, the most basic will be the sonicwall will report a bunch of spoofed traffic.
One option is to connect both switches together and create two vlans that span across both switches. Connect the routers and the WAN side of the FW to VLAN 1. Connect the LAN side and the servers to VLAN 2. If you run HSRP on the routers, that is your default gatewway for the firewall. Here is a logical diagram. Let me know if you need help configuring ...
What I mean is I want no NAT translation.
That is the default behaviour. Adding NAT translation between neighboring subnets would not be an 'enabled by default' feature. Simply adding those subnets into your SonicWall would allow them to communicate as long as your hosts are pointing to it as a default gateway.
I am wondering about how to setup LAN_2. ...
I believe you mean to say that the router has an IP address 192.168.1.1/24, and this is the default gateway for clients in subnet 192.168.1.0/24? The router has another default route pointing to somewhere in the Internet.
Think of a subnet as a house, and gateway as a door. To get into or out of the house you must use the door of that house, neighbor's door ...
The answer will depend on where most of your internal LAN traffic will be going:
If most of your LAN traffic is INTERNALLY BOUND (ie, to a local File Server, Terminal Server, Intranet server, etc) then you definitely want to choose 1 switch as your "main/core" switch and connect the SonicWALL's LAN to it, along with the 2nd switch and any other switches. ...
Well, you normally don't make the port that the PC "on the VLAN" connects to a trunk, and that's probably the bulk of your problem. So the PC isn't actually ON the VLAN, regardless of what you set its IP address to.
The PC conection port should be set to be a member of the VLAN, the VLAN should be that port's PVID, and the VLAN should go untagged out the ...
It may be seen, today, as a poor design, but it's a perfectly valid configuration. The nodes in one subnet are mostly unaware of those in the other subnet. (yes, they can see each others broadcast traffic, but it isn't a problem.) This is no different from running other layer-3 protocols within the same broadcast domain.
DHCP servers accept very few options from clients; though as you point out in comments a few options are sent by the client in the DHCP REQUEST, such as Vendor class identifier (option 60) and the more-common Client Identifier (option 61) and Parameter Request List (option 55).
I've found no way to send this option from a Sonicwall.
It's no help to you, ...
fter a long series of testing and support calls, Sonicwall produced a 'hotfixed' firmware that seems to fix this issue by adding a check box in the interface configuration to allow duplicate MAC addresses for devices that have multiple IP addresses on a single interface. So far this has proved to resolve the issue.
Hotfix # 142099
No word yet on if this ...
Go to Network->Routing. Add a new Route Policy.
Source = PBX (192.168.28.2)
Destination = Any
Service = Any (or the specific services you want routed over X2)
Gateway = X2
Default Gateway Interface = X2
Metric= something less than 20 (10?) so that it preempts the other
That should do it.
In a word: NO.
Your IP address changes when you change ISPs. So any calls currently active on the now-down-ISP will fail. (there may be some trickery that could get the call(s) to redirect/forward to a new SIP endpoint, but I don't think that can work with the current endpoint unreachable.)
If you have a tunnel to your internet voip provider, then yes, you ...
On SonicWALLS, in version 5.x (and 6 too, I imagine) this is known as "Interface Trust". To adjust this setting, go to Network -> Zones and check the box to "Allow Interface Trust" to resolve this issue.
I will caution you however that if you are using the WLAN zone which has interface trust disabled by default, and you are using a SonicPoint with version 5....
I understand that most of the CCTV traffic will be confined to the LAN under X6 traffic because communication is between your cameras and the recording device.
Also, I understand that the only traffic that will flow throught X6 will be things like camera control, DNS, updating firmware, etc. I mean, there are no heavy traffic from CCTV LAN to the rest of ...
Set user for guaranteed speed of 1Mb and max speed of 2Mb.
This is absolutely possible. Dell has an article outlining this specifically; How To Configure Bandwidth Management with limits Per IP (SW12385).
Enable Advanced Bandwidth Management
Activate bandwidth management on WAN interface and declare the interface speed
Generate a new bandwidth object and ...
By default, communication intra-zone is allowed. You just enter in Firewall->Access rules, select LAN->LAN and unmark the last rule wich allow intra-zone connections.
In my opinion, if you don't want communication at all, put X2 and X2:V1 in different zones.
By default the LAN Zone has Interface Trust enabled, which means all interfaces within the same Zone trust each other (pass traffic). Go to Network, Zones, and Edit the Zone in question (LAN) and remove the checkmark from Allow Interface Trust. This will remove the auto-added LAN<->LAN Allow ANY/ANY/ANY rule.
Alternatively if these are NOT really both ...
I'm quoting what is posted on the Psiphon page:
You can only establish connections via Psiphon by using the following ports:
53, 80, 443, 554, 1935, 7070, 8000, 8001,
If you block these ports, you will also be blocking a lot of services in your network.
You need to do Deep Packet Inspection if you want your really block Psiphon.
You certainly can do MANY:1 NAT -- that is: have several Public WAN IPs point to 1 internal LAN IP.
Just create Address Objects for each WAN IP and put those Address Objects into an Address Object Group. Then create your NAT (and Firewall) rule using the Address Object GROUP. Inbound Internet traffic destined to any of the Public IPs in the Address Object ...
You may be running into the fact that some firewalls only allow syslog to be sent from them via their management interface (and not directly out the port facing towards your SaaS/logging provider).
Aside from that, syslog will be sent to a remote server via UDP port 514 by default - ensure that this is allowed outbound from your firewall for all your ...
Your NTP server is behind your NAT (firewall). UDP is connectionless from the point of view of the application and OS and for most network appliances along the way.
For your NAT firewall, however, it records whenever a UDP packet goes out so that a response from the other end will end up being redirected to the same computer inside your network. These ...
This sounds like an issue with traffic-selectors - if you are using policy-based VPN on both sides, you need to make sure the policy (eg: traffic you permit over the tunnel) is the same but reversed on each side. eg:
From Side A Network to Side B Network then tunnel
From Side B Network to Side A Network then tunnel
High availability is a big and sometimes tricky topic, depending on what you actually want to achieve. If you want to maintain running TCP connections, for example, with sub 100 ms retransmission, you've got some work to do.
On the other hand, a typical business who wants to maintain internet connectivity might have simpler targets: no single cable, box, ...
As boomi has already pointed out, this is no routing issue but a firewall issue. Most firewalls have an implicit deny all rule at the end of their policy list, so everything you haven't explicitly permitted is blocked.
I'm not familiar with SonicWall but basically you need to add a firewall rule to allow your guest to access the printer. Something in the ...
It sounds like what you want is hairpin routing. This is not a good idea because it is suboptimal routing, involving NAT (a kludge that should be avoided whenever possible), and it unnecessarily burdens your firewall and slows your communication.
If you really want to do it, there are documents describing how. For example, this one:
Configuring access to ...