Page 1 of 1

NAT Traverse OK/!OK

Posted: Mon Jul 01, 2019 6:49 pm
by ZEE
The objective is connect from a remote PC
to a private IP device inside a LAN
behind a router with NAPT (the usual ISP supplied routers)
( LAN IP(s) are in range 192.168.1.0/24 or 10.0.0.0/8 )
(access from a external client to a internal machine that has the SE-Hub/Bridge)
+
When connecting using *.vpnazure.net DDNS it works
I can do NAT Traverse over a ISP router
(only using SSTP VPN in port 443/HTTPS)
but the connection is rather slow...
+
When connecting using *.softether.net DDNS
I can´t connect with neither protocol (SSTP:443/SE-VPN:555/OpenVPN/...)
nothing seems to work...
+
+
My preference would be
to connect using the SE-VPN Protocol over port 5555/TCP
+
Anybody cares to give a explanation on how to this...
and if possible gave some technical insights
over why VPNAzure works but SoftEther.net don´t...
(I´m not talking about the DDNS, that works OK)

Tested with Thomson, Hitron, Asus, TP-link, etc. router
Thanks, ZEE

Re: NAT Traverse OK/!OK

Posted: Mon Jul 08, 2019 11:42 pm
by centeredki69
ZEE - "behind a router with NAPT (the usual ISP supplied routers)" & then "Tested with Thomson, Hitron, Asus, TP-link, etc. router".
---Are you double NATed meaning ISP router & then one of the Thomson, Hitron, Asus, TP-link at the server location? If so it will be hard for SE to transverse a double NAT
ZEE-I can´t connect with neither protocol (SSTP:443/SE-VPN:555/OpenVPN/...)
-----The NAT-traversal will only work using the SE protocol or the SSTP:443 with Azure.NEt enabled. All other standard protocols will need port forwarding.

Re: NAT Traverse OK/!OK

Posted: Tue Jul 09, 2019 12:00 am
by centeredki69
ZEE- Anybody cares to give a explanation on how to this...and if possible gave some technical insights over why VPNAzure works but SoftEther.net don't...----------Yes it should be possible.
---With VPNAZURE your SE Server establishes and maintains a connection from inside your firewall out to a relay server hosted on MS Azure by the SE/Un of Tsukuba developers for FREE. When a client connects using the VPNAzure it is connecting to the relay server which then send only the authentication info to your SE server and once authentication is complete a direct connection is made from the client to the SE server so all payload data is direct and not through the Azure server. The softEther.net is a direct Dynamic DNS

Re: NAT Traverse OK/!OK

Posted: Tue Jul 09, 2019 12:01 am
by centeredki69

Re: NAT Traverse OK/!OK

Posted: Sun Sep 15, 2019 5:57 am
by kls
centeredki69 wrote:
Mon Jul 08, 2019 11:42 pm
Are you double NATed meaning ISP router & then one of the Thomson, Hitron, Asus, TP-link at the server location? If so it will be hard for SE to transverse a double NAT
I know this is very old thread, but it is the only one mentioning double NAT. Is it true that SE won't work with double NAT without going through VPNAzure?

Re: NAT Traverse OK/!OK

Posted: Tue Jan 19, 2021 2:05 pm
by ZEE
"---Are you double NATed " ... "it will be hard for SE to transverse a double NAT"
"---The NAT-traversal will only work using the SE protocol or the SSTP:443 with Azure.NEt enabled... other standard protocols will need port forwarding..."

Thanks @centeredki69 for this information...

In that case I was not double-natted... the problem was an very-agressive firewall... solved, OK!

about the connection mechanics via azure.net,,, it confirmed my suspections...
usually I avoid forwarding ports... and the vpnazure.net over mpx/443 works fine...

Thanks again!

Re: NAT Traverse OK/!OK

Posted: Tue Jan 19, 2021 2:10 pm
by ZEE
"---With VPNAZURE ... establishes connection from inside your firewall ... to a relay server ... MS Azure "
"...relay server ... send only the authentication info to your SE server ... "
"...once authentication complete a direct connection is made from the client to the SE server
"...so all payload data is DIRECT and not through the Azure server
"...The softEther.net is a direct DDNS"

Thank you for this clarification...
very direct and informative...
and confirms what I thought/probed the mechanism was...

;-)