Menu

Join the Conversation

To sign in, use your existing MySonicWall account. To create a free MySonicWall account click "Register".

Sign In Register

Adding WAN->LAN bridge causes heavy lag on VPN and management interface

rrowlandrrowland Newbie ✭
in Firewall Management and Analytics

I have a SonicWall TZ670 in a data center, hooked up to a NetGear 52 port smart switch. I'm trying to do what I thought would be a very basic set-up: give each server (all hooked into the smart switch) their own public IP from the subnet provided by the data center, and internal IP. Everything is working, except that when I attempt to create a bridge (native or L2) from the WAN to the LAN port, it assigns addresses to my servers as expected but causes the VPN and the management interface to lag extremely heavily -- they become unusable until I revert the change via CLI (which is also extremely laggy).

For the sake of example, let's say my subnet is 100.100.100.128/27. The important IPs are: *.129 is the gateway, *.132 is the IP being used for the firewall management and VPN, and *.133-*.158 should be assigned to the servers.

My in port is X8, which is a fiber optic port. The configuration is set to a static IP WAN. The static IP is set to *.132 with a subnet of 255.255.255.224 and a gateway of *.129. The single fiber optic line supplied by the DC is plugged in here.

My LAN port is X6, a copper line to the smart switch. This is set up as a static IP LAN. IP is set to 10.10.10.1, subnet 255.255.0.0, gateway 0.0.0.0. This successfully assigns internal IPs to the servers via DHCP.

I also have a second copper connection to the switch on X7 that I added after running into this issue for a couple of days, hoping it would help solve the lag issue caused by bridging (it didn't).

That all works. I can VPN in, RDP into the servers via their internal IP, set static internal and public IPs. What I cannot, for the life of me, get working is forwarding the traffic on public IPs .133-.158 to the machines.

The closest I have gotten is creating a Native Bridge on a Virtual Interface to X6 (later I tried the same directly on X7 to the same effect). This allows me to connect to the machines via RDP using the public IP as expected, however, it has the devastating side effect of making VPN unusably slow, and the firewall management console unresponsive and unusable. I found the same laggy behavior when I set the bridge up as an L2 bridge.

My current theory is that this has something to do with the VPN and management IP (.132) being included on X8 and therefore being included in the bridge, causing some kind of loop or other bad behavior. I have spent countless hours trying to figure a way to only bridge .133-.158 to the switch, hoping that would fix the issue, but have been unable to figure a way.

I'm pulling my hair out at this point; this seems like a fairly common setup case and I was expecting it to be much easier, not to spend 3 days running into the same brick wall. So if anybody who has set up similar networks could drop me a hint I'd be extremely appreciative.

Category: Firewall Management and Analytics
Reply

Answers

  • SaravananSaravanan Moderator

    Hi @RROWLAND,

    Thank you for visiting SonicWall Community.

    Sorry to hear that you are having a hard time. Let me try to help you out. I would like to understand a bit about your scenario.

    • When you say VPN becomes unusable? Which VPN you are referring to Site to Site VPN or GVC or SSLVPN? What exactly happens with VPN access? Is there a delay in access or VPN doesn't come up? Please explain.
    • What about the firewall's management access via web, CLI and ping when the bridging is done?
    • May I know your requirement to bridge LAN and WAN interfaces? I can see if some other options available for your setup achievement.
    • Are you trying to access the local servers by directly assigning public IP's on them or assigning private IP's on them is fine?
    • What is the current firmware on the SonicWall box?

    Thanks in advance.

    Regards

    Saravanan V

    Technical Support Advisor - Premier Services

    Professional Services

  • rrowlandrrowland Newbie ✭

    Hi Saravanan, thanks for the quick response! I'd be happy to clarify:

    • I'm using the IPSec VPN. When I say it becomes unusable, I mean I am able to connect, however, there is extreme packet loss and I am unable to really do anything. Attempting to connect to anything, internal or external, is extremely slow and often times out. Even when pinging internal IPs (such as the gateway at 10.10.10.1) I observe over 50% packet loss. In contrast, when the bridge is not set up, VPN works perfectly -- everything loads snappy, I observe no packet loss.
    • There is similar behavior with the firewall's management web and CLI access. When the bridge is enabled, communication with them is very slow, and more often than not my requests time out. The web interface is practically unusable; I need to log into the CLI to disable the bridge, at which point things return to normal and the web interface and CLI are no longer experiencing high latency/packet loss.
    • My requirement is that I have a fiber optic line coming from the data center, and am assigned a /27 public IP subnet from them. I need the servers plugged into my switch to be assigned public IPs from that range. The firewall and VPN (which uses the same IP) also get their public IP from this range. There are more details on this in my original post. Let me know if you need any other clarification.
    • The servers should each have a public IP and an internal IP. I plan to gate RDP access to the machines to internal IP from on the VPN, however, these servers are addressable by our customers and therefore also need a public IP.
    • Firmware is version 7.0.1-R1262


  • SaravananSaravanan Moderator

    Hi @RROWLAND,

    Thanks for your clarification.

    It looks like bridging is a valid problem here. We may need to find the CPU usage when the bridging is done and see which task is consuming more CPU. For time being to address the issue, your requirement of having the servers to use public IP's, we can use transparent bridging mode in-order to be able to access the servers directly using their public IP's instead local IP. No portforwarding is required for this scenario and just an WAN to DMZ access rule is enough.

    Please take a look at the below KB article and let me know if this can suit your requirement.

    https://www.sonicwall.com/support/knowledge-base/configuring-interfaces-in-transparent-ip-mode-splice-l3-subnet/190315113832572/

    Also, feel free to update here for other questions/clarifications. I'd be happy to clarify and assist.

    Regards

    Saravanan V

    Technical Support Advisor - Premier Services

    Professional Services

  • rrowlandrrowland Newbie ✭

    I switched over to the transparent mode as suggested, and I'm still experiencing the same issue. I'm able to get public IPs for all servers, however, over time my VPN and management connections will slow down until they are unusable. Restarting the firewall seems to alleviate the issue for a while but it inevitably returns to this state, and of course, this isn't a viable long-term solution in production. I have logged into the CLI and can verify that the CPU isn't going over 11% during these issues.

  • SaravananSaravanan Moderator

    Hi @RROWLAND,

    Thanks for trying out the suggestions. It looks like we need to work on the issue in real-time to understand the cause of the latency when bridging (Layer2/Native/Transparent) is configured on the SonicWall. I would recommend you to open a support case as per below Support contact web-link and take real-time assistance via remote session.

    https://www.sonicwall.com/support/contact-support/


    Regards

    Saravanan V

    Technical Support Advisor - Premier Services

    Professional Services

Sign In or Register to comment.