Simple Port Based Policy Issue

RetoReto
in Firebox - Other

Hi all,

One of the users would like to establish a OpenVPN tunnel from his PC to his Synology device in the cloud over port 1701 (this is not the official port for openvpn).

So I created a custom policy and added a packet filter using port TCP 1701. As source I specified the fixed IP of the workstation and as destination the IP of the Synology.

Nothing else modified.

Now when the user tries to establish a VPN tunnel the Firewall shows:
Allow IP-of-PC Destination-IP L2TP trusted external application identified outgoing-00
5 sec later
Deny Destination-IP Firebox-IP 56751/UDP external firebox denied Unhandeled external packet-00

It looks like the incoming UDP packet cannot be related to the prvious outgoing session --> NAT issue?

I also tried to modify the Advanced Settings and unselect 1:1 NAT and under Dynamic NAT I selected "all trafic in this policy".
But this did also not help.

Any ideas on how to solve the issue?

Comments

  • Bruce_BriggsBruce_Briggs
    edited November 2022

    The WG predefined L2TP packet filter is for UDP port 1701, not TCP.

    What is the source port on the allow log message?
    The reply packet should have this as the dest port, and the reply packet source port should be the dest port on the allow message.
    If not, then the packet from the Internet does not match the sent packet, and will be denied.

  • james.carsonjames.carson Moderator, WatchGuard Representative

    If it's coming back as unhandled, it'll be coming back as a different connection. I'd suggest asking the user to double check what ports they have configured (it sounds like they may be using a different port for their data channel) and build a rule around that as needed.

    56751 sounds random, the user may have possibly not defined the port on their server?

    -James Carson
    WatchGuard Customer Support

  • RetoReto

    I modified the rule to have TCP:0 and UDP:0 (this should allow all ports).
    Still the traffic is timing out.

    On the PC where OpenVPN client is installed the log shows the following:

    [Nov 11, 2022, 09:25:01] Connecting to [87.102.xxx.xxx]:1701 (87.102.xxx.xxx) via UDPv4
    ⏎[Nov 11, 2022, 09:25:10] EVENT: CONNECTION_TIMEOUT BYTES_OUT : 840
    PACKETS_OUT : 60
    CONNECTION_TIMEOUT : 1
    N_RECONNECT : 5
    ⏎[Nov 11, 2022, 09:25:10] EVENT: DISCONNECTED ⏎

    The Traffic Monitor on the watchguard shows:

    Any ideas why the UDP traffic that is sent back by the OpenVPN Server using some random high ports are being blocked?

  • Bruce_BriggsBruce_Briggs

    Best to ask that question on a OpenVPN forum

  • james.carsonjames.carson Moderator, WatchGuard Representative

    They're coming back as a new connection -- if we can predict the port numbers it'd be pretty easy to make a rule to forward them to that user's machine -- but they appear to be random.

    I'd suggest asking folks at OpenVPN or the NAS manufacturer if there's a way to control this.

    -James Carson
    WatchGuard Customer Support

  • RetoReto

    Hi all, many thanks for your support. I checked the settings on the Synology VPN Server again and found, that I can switch from UDP to TCP (using the same port as mentioned above). Also the client software was modified to use TCP instead of UDP. Now the connection worked and the OpenVPN tunnel could be established.
    I noticed that the traffic comming back also uses random high ports but using TCP the firewall can match them to the originating traffic.

Sign In to comment.