You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Before you submit an issue, please read the following:
Is this a question? NO
If the answer is "yes", then please ask your question on www.vpnusers.com.
The issue section on GitHub is reserved for bugs and feature requests.
If the answer is "no", please read the following:
We provide a template which is specifically made for bug reports, in order to be sure that the report includes enough details to be helpful.
Please use or adapt it as needed.
Prerequisites
Can you reproduce? YES
Are you running the latest version of SoftEtherVPN? YES
SoftEther version:5.02 Component:SERVER Operating system:Windows Architecture:64 bit
[In case it's a computer with known specs, such as the Raspberry Pi, you can specify it omitting the details.] Processor: Intel 13th Gen/Not significant
Description
This has become a problem with modern firewalls.
Firewalls way back would need IPs to unblock with ports
Firewalls yesterday would take FQDNs and look them up and allow them with specific ports
Firewalls today REQUIRE the FQDN to be in the request
Some IT Admins are okay with allowing entire IP to communicate, some insist on requiring a hostname.
This causes a situation in a cluster mode it will break and VPN will not establish (I have not tested with a single server). I need the Public IP to also allow a FQDN and the requests need to use the FQDN
Expected behavior:
[What you expected to happen]
Allow entry of a FQDN and instruct the client to use the same FQDN
Actual behavior:
[What actually happened]
Only Public IP is available
Steps to reproduce
Manage the VPN Server
Enter Clustering Configuration
Set to Cluster Member Server
[you can only set a Public IP, needs to also allow Public FQDN]
The text was updated successfully, but these errors were encountered:
For a test scenario, you can use pfSense (firewall for the client side) and only allow communication to the FQDNs set for the controller and cluster members.
Having looked at the code, this is likely harder than requested I am guessing. The IP is converted to int32?? then stored (at least in memory?) this way. Should a separate method be used or should it all just be converted to string?
Code files identified so far involved: Network.c, Pack.c, Admin.c, Server.c
Hi, there!
Thank you for using SoftEther.
Before you submit an issue, please read the following:
Is this a question? NO
If the answer is "yes", then please ask your question on www.vpnusers.com.
The issue section on GitHub is reserved for bugs and feature requests.
If the answer is "no", please read the following:
We provide a template which is specifically made for bug reports, in order to be sure that the report includes enough details to be helpful.
Please use or adapt it as needed.
Prerequisites
SoftEther version: 5.02
Component: SERVER
Operating system: Windows
Architecture: 64 bit
[In case it's a computer with known specs, such as the Raspberry Pi, you can specify it omitting the details.]
Processor: Intel 13th Gen/Not significant
Description
This has become a problem with modern firewalls.
Firewalls way back would need IPs to unblock with ports
Firewalls yesterday would take FQDNs and look them up and allow them with specific ports
Firewalls today REQUIRE the FQDN to be in the request
Some IT Admins are okay with allowing entire IP to communicate, some insist on requiring a hostname.
This causes a situation in a cluster mode it will break and VPN will not establish (I have not tested with a single server). I need the Public IP to also allow a FQDN and the requests need to use the FQDN
Expected behavior:
[What you expected to happen]
Allow entry of a FQDN and instruct the client to use the same FQDN
Actual behavior:
[What actually happened]
Only Public IP is available
Steps to reproduce
Manage the VPN Server
Enter Clustering Configuration
Set to Cluster Member Server
[you can only set a Public IP, needs to also allow Public FQDN]
The text was updated successfully, but these errors were encountered: