- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
01-29-2025 01:25 PM
I am Boundary Technician with the US AF, and currently TBS with a customer who are attempting to est. a tunnel with the following applications: wireguard and zerotier. The tunnels are not coming ups for some reason. Both applications are using the dynamic-udp as a standard port. Question, how to I request a port research / change for the two applications? If dynamic-udp is correct, please advise!
01-29-2025 08:20 PM
Hi @mccorveyr ,
How does the traffic traversing your firewall look? Do you see it being allowed despite the tunnel not being successful for your customer? If so, I would run a packet capture. For WireGuard, a handshake takes place between the initiator and the responder. The handshake consists of two messages:
The handshake process as well as the tunneled traffic is encrypted, but you can still check to see if the initiator message, responder message, and subsequent transport data packets are being sent. Since the tunnel is not coming up for your customer, Id assume that message 1 or message 2 is not going out or returning.
If you don't see traffic at all, then there is likely a client config issue or your may have another device blocking the connection before it hits your Palo. If you see the traffic being denied or hitting your interzone default policy, Id ask your customer to test with the Wireguard default port to get the traffic out (this can be configured in the WireGuard config) If you see traffic being allowed, what does the detailed log view show? Id take a look at the bytes sent/returned as well as verifying NAT. If all that looks good... its being allowed, bytes sent and returned, using the correct NAT, then what you can do is adjust the UDP session timeout on the firewall. The default is set to 30sec. Try setting to 180sec to accommodate Wireguard handshake and keepalive.
At this point, you've done a good amount of triage and config on your end. If the tunnel still doesn't come up, read the following from WireGuard and ask your customer to modify config:
" By default, WireGuard tries to be as silent as possible when not being used; it is not a chatty protocol. For the most part, it only transmits data when a peer wishes to send packets. When it's not being asked to send packets, it stops sending packets until it is asked again. In the majority of configurations, this works well. However, when a peer is behind NAT or a firewall, it might wish to be able to receive incoming packets even when it is not sending any packets. Because NAT and stateful firewalls keep track of "connections", if a peer behind NAT or a firewall wishes to receive incoming packets, he must keep the NAT/firewall mapping valid, by periodically sending keepalive packets. This is called persistent keepalives. When this option is enabled, a keepalive packet is sent to the server endpoint once every interval seconds. A sensible interval that works with a wide variety of firewalls is 25 seconds. Setting it to 0 turns the feature off, which is the default, since most users will not need this, and it makes WireGuard slightly more chatty. This feature may be specified by adding the PersistentKeepalive =
field to a peer in the configuration file, or setting persistent-keepalive
at the command line. If you don't need this feature, don't enable it. But if you're behind NAT or a firewall and you want to receive incoming connections long after network traffic has gone silent, this option will keep the "connection" open in the eyes of NAT."
Feel free to shoot me a PM!
01-29-2025 08:20 PM
Hi @mccorveyr ,
How does the traffic traversing your firewall look? Do you see it being allowed despite the tunnel not being successful for your customer? If so, I would run a packet capture. For WireGuard, a handshake takes place between the initiator and the responder. The handshake consists of two messages:
The handshake process as well as the tunneled traffic is encrypted, but you can still check to see if the initiator message, responder message, and subsequent transport data packets are being sent. Since the tunnel is not coming up for your customer, Id assume that message 1 or message 2 is not going out or returning.
If you don't see traffic at all, then there is likely a client config issue or your may have another device blocking the connection before it hits your Palo. If you see the traffic being denied or hitting your interzone default policy, Id ask your customer to test with the Wireguard default port to get the traffic out (this can be configured in the WireGuard config) If you see traffic being allowed, what does the detailed log view show? Id take a look at the bytes sent/returned as well as verifying NAT. If all that looks good... its being allowed, bytes sent and returned, using the correct NAT, then what you can do is adjust the UDP session timeout on the firewall. The default is set to 30sec. Try setting to 180sec to accommodate Wireguard handshake and keepalive.
At this point, you've done a good amount of triage and config on your end. If the tunnel still doesn't come up, read the following from WireGuard and ask your customer to modify config:
" By default, WireGuard tries to be as silent as possible when not being used; it is not a chatty protocol. For the most part, it only transmits data when a peer wishes to send packets. When it's not being asked to send packets, it stops sending packets until it is asked again. In the majority of configurations, this works well. However, when a peer is behind NAT or a firewall, it might wish to be able to receive incoming packets even when it is not sending any packets. Because NAT and stateful firewalls keep track of "connections", if a peer behind NAT or a firewall wishes to receive incoming packets, he must keep the NAT/firewall mapping valid, by periodically sending keepalive packets. This is called persistent keepalives. When this option is enabled, a keepalive packet is sent to the server endpoint once every interval seconds. A sensible interval that works with a wide variety of firewalls is 25 seconds. Setting it to 0 turns the feature off, which is the default, since most users will not need this, and it makes WireGuard slightly more chatty. This feature may be specified by adding the PersistentKeepalive =
field to a peer in the configuration file, or setting persistent-keepalive
at the command line. If you don't need this feature, don't enable it. But if you're behind NAT or a firewall and you want to receive incoming connections long after network traffic has gone silent, this option will keep the "connection" open in the eyes of NAT."
Feel free to shoot me a PM!
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!